Microservices are relatively new in the field of enterprise software development. And while it’s too early to tell how prevalent they will be, it’s not too early to examine their benefits and drawbacks.

Microservices are so named because they’re designed to break larger applications into more minor, discreet functionalities. Meaning that developers can create a service for just what you need it for and forget about the other aspects of the application that may change over time. It also means that one developer can work on the API of a microservice without worrying about what changes are being made to other services.

A microservice architecture is at least comprised of three different APIs

• Service API
•  Orchestration API
•  Integration-testing API. 

The service API exposes the functionality of a service, the orchestration API exposes the workflow or business logic of the application, and the integration-testing API allows developers to test interactions between services and identify problems within its workflow. Typically, these APIs run in containers either locally or in the cloud.

How to Build Microservices

The best way to build your architecture is to use the design patterns in the “microservice way”: splitting up services into three sections: business, application, and platform-level.

Business Functionality

Business functionality refers to the problem domain for a service. For example, an airline service could expose endpoints for booking tickets and retrieving flight information.

Application-Level Functionality

Application-level functionality refers to using business logic within your service that’s specific only to your application. For example, an airline may want to use a third-party service that calculates the fuel efficiency of particular aircraft.

Platform-Level Functionality

Platform-level functionality refers to using third-party services that are vendor-neutral within your application. For example, an airline may want to use a third-party service that calculates the fuel efficiency of flights.

Pros and Cons of Microservices

Pros 

• being able to change and scale only what you need
• ease of deployment
• reduced time to market
•  lowering your cost. 

Cons

• increased operational overhead
• higher costs for development due to isolation
• increased complexity due to more moving parts.

Why Microservices?

A microservice allows you to know what you’re building, why, and who will use it. This makes it much easier to scale out your application over time. It also means that if your application changes, you can create a new service in a matter of days or weeks rather than having to rewrite the entire application from scratch.

• Performance: You can create microservices that are faster and more efficient than monolithic applications because there’s no need for unnecessary processing overhead.

• Scalability: Microservices can be scaled out to handle increased load. As the business needs change, you can quickly scale up a microservice instead of scrapping it and starting over.

• Reliability: You control which systems are affected by your application failures because you can isolate it from other systems in the system.

• Security: You have increased security controls since all services run within containers with access control lists (ACLs). You can also better enforce security within your application by using configuration management tools, such as Chef or Puppet.

• Agility: Using microservices lets you quickly spin up new services whenever necessary and tear them down later without affecting other services, which helps keep your development team agile.

Architecture Decisions

Each of the above microservices have distinct requirements, such as the following:

Planning: Deciding where to place business functionality, application-level functionality, and platform-level functionality is crucial. It would be best to consider how these functions will be used, what security controls you want to use, and what tools you might choose for configuration management. For example, you may choose to create microservices that can run in containers locally or in the cloud or both. The service so designed could be integrated with other platforms and systems externally or internally. If running locally, a team member can accept changes from different sources without affecting other systems or applications.

Designing: The design of the three sections should be exactly the same so that developers don’t have to learn new APIs when working in each section of the architecture.

 Implementing: Developers will need to create RESTful endpoints served by your chosen framework, such as Spring, Laravel, Rail, or any other suitable framework.

 Monitoring and Performance: You’ll need to monitor each microservice at the application and platform levels. You’ll also need to monitor the components that make up a microservice.

To deal with architectural decisions, you have several options:

Pragmatic: Use common frameworks and all the required mechanisms so that you can leverage that functionality in all your applications. For example, use Spring MVC for web services and Spring Boot for Java solutions.

Smart: Using an existing technology such as Docker will be easier than creating your own infrastructure. You can then layer what you need to accomplish what is required by your application on top of Docker.

Other options that might work for you are microservices that run in containers within Kubernetes such as Google GKE, AWS ECS or Azure Container Services (ACS).

Conclusion

As you can see, microservices are a useful tool for building applications. They allow developers to separate application functionality into several services that can be easily maintained and scaled out without affecting the rest of the application. Each service has its API therefore making integration with other platforms, systems and applications easier. You can also better enforce security controls through configuration management tools such as Chef or Puppet.

The process of splitting your application into microservices is not always straightforward. Still, it is a great way to bring the overall process of your development team in line with modern thinking about developing software. It also gives you greater flexibility in developing and delivering new features to your customers or users.

To read about APIs, see this article.