Delving Into the Microservices Architecture

by: John Mueller

Microservices

Although microservice architecture is fairly new, the basic concept behind it is one that will seem familiar to many software professionals. The guiding principles behind microservices include:

  • Using small, single purpose, service-based applications to create a fully functional application (each single purpose application is a microservice)
  • Creating each microservice using the most appropriate programming language for the task
  • Obtaining application data using the most efficient data management technique for the particular microservice
  • Developing some sort of lightweight communication between each microservice
  • Communication occurs using protocols such as REST, so that the pipe is dumb, but the microservice is smart
  • Employing a decentralized approach to managing the application by monitoring each microservice separately
  • Relying on each microservice as needed to build any number of full-fledged applications (desktop, mobile browsers, native mobile apps, and even APIs)

A microservice is extremely focused and performs a distinct function. For example, you might include a customer management microservice, an order entry microservice, a shipping microservice, and other microservices on your servers that could support any application, not just one application. The shipping microservice doesn’t care which application requests that it ship something to a customer. In fact, it doesn’t care what the item is or who the customer is. All the microservice understands is that it must ship something to someone somewhere. The task is focused and distinct.

The microservices architecture presents a number of benefits to developers. One of the more important benefits is that each microservice runs in its own process on a system that you can physically locate anywhere. A failure of any of these microservices won’t bring down the entire application. At most, you lose an application feature. In fact, you can easily create redundant microservices so the application senses the loss of the microservice and simply connects to another microservice of the same type. In short, applications become incredibly reliable using the microservices architecture.

Borrowing applications from other companies becomes less of a problem when using the microservices architecture. For example, many of the companies that create microservices architecture applications rely on Amazon Web Services (AWS) to provide e-commerce support.

Deployment issues also become less of a problem. When working with a monolithic application, any change requires testing and deployment of the entire application. Using the microservices architecture means that you redeploy individual application features as needed—the application never really goes offline.

User training becomes less of a problem too. Applications change at a more consistent pace. A user sees a new item added to one application feature one day and another item added somewhere else later. Instead of hiring someone to teach users about a large number of features in a single deployment, an e-mail about the new item may serve the same purpose.

Applications use resources more efficiently with the microservices architecture. Instead of scaling the entire application up, only those features that receive heavy use receive additional resources. As a result, you can run the application on less hardware and receive better results because the application remains fully optimized all the time.

The microservices architecture also affects development teams. Instead of creating huge teams that are hard to manage, each microservice has its own team. The team remains small and flexible. It’s likely that at least one team member (and probably more) understand the microservice completely. The team that couples the microservices together also remains small because all this team has to understand is that interacting with a specific microservice provides access to a particular application feature. How that feature works is immaterial.

When a fault does occur in the system, the source of that fault is much easier to discern (with proper monitoring) because each microservice is isolated. When you suddenly find that you can’t ship something, you look at the shipping microservice, not the customer management microservice.

The idea of the microservice architecture may seem much like using a library. The two do share some common concepts. For example, both provide the means to modularize code to make it independently upgradeable and replaceable. In short, the code becomes a self-contained component.

However, the difference comes in when you view the manner in which the application accesses the component. When working with a library, the developer imports the library code into the application. The library becomes part of the application and calls to it are made as in-memory function calls. The code is part of the same process as the application so a failure in the library becomes a failure in the application.

The microservices architecture relies on microservices that are running independently of the application, in their own process. The application makes an out-of-process call to use the microservice. If the microservice fails, the service it provides becomes unavailable, but the application need not crash. All it needs to do is find another source for the service or tell the user that a particular feature is temporarily unavailable. Life continues as if nothing has happened.

Monolithic applications tend to use huge development teams that are split along functional lines, such as a team for user interface, another for server-side logic, and another for database management. When a new feature is needed, the feature is often wedged into the application in an inappropriate place because the team creating the feature doesn’t have access to the code that would place the feature in the correct location. As a result, applications become bloated and difficult to understand, modularization is affected to a large degree because changes violate component integrity.

The microservices architecture divides applications along function lines, so there is a team for each of the major tasks an application must perform. The customer management microservice has its own complete team that works on every aspect of this microservice. The teams are small and quite focused. In addition, they run their microservice, so that the team that builds the application also runs the application. This means that the team sees the problems with the microservice on a daily basis and is better able to fix them.

Application Programming Interfaces (APIs) make all of the pieces of the microservices architecture work together. Unlike libraries, where you import the code into your application, microservices work as remote procedure calls. This means that your application creates a query to the microservice running on another system. The call is similar to working with a Web service in many respects.

The vast majority of microservices rely on Representative State Transfer (REST) APIs. It’s the same technology used by many Web services, so your team already understands how to use it. The calls and data rely on HTTP as a transport, so you don’t need any special protocols in place.

It’s important to realize that a call from a client could contact a single front-end component that will then fan the requests out a number of back-end components. For example, a customer request might obtain the customer contact information from one microservice, a credit rating from another microservice, a list of recent purchased from still another microservice, and sales suggestions from a fourth microservice. In fact, the back end components can further delineate calls to other microservices for specific information.

There are so many benefits to working with the microservices architecture that many organizations with huge application requirements have made the switch already. You can find large applications using this architecture at:

  • Amazon: http://highscalability.com/blog/2007/9/18/amazon-architecture.html
  • eBay: http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
  • Netflix: http://techblog.netflix.com/

Further Resources

  • 8 Questions You Need to Ask About Microservices, Containers Docker in 2015 by Andrew Phillips: http://blog.xebialabs.com/2014/12/31/8-questions-need-ask-microservices-containers-docker-2015/
  • How we build microservices at Karma by Stefan Borsje: https://blog.yourkarma.com/building-microservices-at-karma
  • Microservices by Martin Fowler: http://martinfowler.com/articles/microservices.html
  • Pattern: Microservices Architecture by Chris Richardson: http://microservices.io/patterns/microservices.html
  • Why 2015 will be the year of microservices by Eric Knorr: http://www.javaworld.com/article/2863409/soa/why-2015-will-be-the-year-of-microservices.html

Article source: http://feedproxy.google.com/~r/SmartBear/~3/I_66Ew6qBdw/

Comments

Powered by Facebook Comments

Leave a Reply

Your email address will not be published. Required fields are marked *