everythingpossible - Fotolia

Discover the role of smart endpoints in microservices

In part one of a two-part series, a software architect describes how his organization has used microservices and smart endpoints.

This is part one of a two-part series about the tradeoffs between smart endpoints and smart pipes. This article focuses on using smart endpoints. Read part two here.

Microservices are a design philosophy for building enterprise applications using lightweight business domain components for new cloud services. This style of development uses existing enterprise infrastructure frameworks, including enterprise service buses and API management gateways. Both of these integration backbones have been focused on putting the intelligence into smart endpoints. Now though, with the evolution of software networking, enterprise architects are starting to think about using "smarter pipes" to implement at least some of the networking functionality required for these types of applications.

"By placing intelligence into the networks and the middleware intermediary and gateways, enterprise architects can simplify the development at the endpoints, mobile applications or the services that are connecting with each other," said Chris Haddad, vice president of platform evangelism at open source software company WS02. "But when teams introduce more intelligence into the middleware, it seems like we are trying to move from a dumb pipe to a smart pipe, so it is almost at odds with microservices."

Object-oriented programming meets SOA

Lynden Inc., a freight and logistics company based in Alaska, turned to microservices to help streamline the development of B2B applications. Rob Terpilowski, a software architect at Lynden, said he views microservices as an extension of object-oriented programming models applied to service-oriented architecture, or SOA. Microservices make it possible to use discrete components that can be unit tested, upgraded, modified and scaled in real time without having to take down other system components.

Terpilowski has found that this approach makes it possible to independently modify services and scale them. He said that many companies, including Lynden, have monolithic applications. The microservices approach makes it easier to modify components rather than the entire application.

One example has been a Web customer-facing mobile app. The microservices approach enabled Lynden to outsource the front-end development for a Web and mobile application to a consulting group. Because Lynden has implemented an agreed-upon standard regarding representational state transfer and how objects are updated and deleted, Lynden is in a better position to decouple the development.

By placing intelligence into the networks and the middleware intermediary and gateways, enterprise architects can simplify the development at the endpoints.
Chris Haddadvice president of platform evangelism, WS02

In the future, Lynden software architects would like to replace data repositories that have to be accessed with specific types of code with microservices that could access back-end data. Such access would enable the use of back-end applications for customer service personnel, truck drivers and business partners. "It is a new paradigm of trying to break down the data access into something that is consistent across the enterprise," said Terpilowski.

Lynden is currently focused on using smart endpoints for implementing its microservices components. This approach should work well for the foreseeable future. According to Terpilowski, Lynden has stayed away from using smarts in the routing mechanism. He added, "I do see where if you have a lot of applications that need to make use of a security model, then building that into the routing mechanism would be beneficial and time-saving in the long run. It could be that at some point in the future when we are having to rebuild a lot of this stuff, it makes sense to put more intelligences into the routing."

With Lynden's first foray into microservices, the idea is to keep applications as stateless as possible. Even though these services are running as different applications, they still run on a single app server, which manages security at the app server level. Terpilowski said, "In a sense, we do have some smarts built into the network, but we are not explicitly putting that in there." He expects this will be a problem that will need to be solved in the future. Terpilowski continued, "In the long run, we are seeing that our single app server will go away and we will have to deal with network latency issues because each app will be on a different server."

Next Steps

Why microservices should be on your radar

Dig Deeper on Cloud architecture design and planning