Microservices are an interesting and increasingly popular approach to the modularization of an application. However, they are not suitable for every application use case. It’s important to consider how microservices interact and interconnect with each other and other services, such as the cloud. If you’re still trying to make sense of the value of breaking an application into microservices, it’s best to weigh your options before moving away from a monolithic approach to application development.
What is a microservice?
An application is developed as a set of services or functions. By using microservices, these functions can be independently developed, tested, built, deployed and scaled for easier management and use. Microservices offer many benefits to developers, such as flexibility and agility, especially when developing applications in the cloud, but it is vital to understand the domain you’re working in before adopting this architectural approach. If you have a solid understanding of what the boundaries and the dependencies are, microservices could be the right move, versus sticking with a monolithic approach.
Here are 7 things to consider before committing to a microservices approach:
#1 How small is micro?
Application services are built around specific business capabilities or functions, and the key question here is, “How small is a service before it qualifies as a potential microservice?” This is an important question because when you begin separating microservices from a monolithic application, you need to consider if a service would be small and contained enough to achieve the flexibility or agility you are seeking when it stands alone. If it’s really critical to the rest of the application, it may as well stay as is.
#2: How do microservices scale?
Packaging application services as distinct units using a container platform such as Docker is a great approach for horizontally scaling. However, this approach is not limited to just microservices. Scaling can be also achieved in a monolithic structure by creating logical clusters of the application that can handle a particular subset of the traffic, such as latency-sensitive workloads. This allows you to tune each cluster to its given workload, and scale them individually to handle surges in traffic, without having to break the application apart into microservices.
#3: Are microservices more agile?
Agility starts with the process that involves an iterative and incremental software development framework (“scrum”) and then is enhanced in development practices, such as continuous integration (e.g., time-driven and behavior-driven development). Given the maturity of DevOps with containerization and domain-driven design, microservices can create greater agility and increased productivity. However, for a relatively small application or one that is less complex, monolithic application development can be best in achieving agility and high productivity goals, as compared to a microservices design.
#4: What is the best way to deploy microservices?
When an application is designed with multiple autonomous services, you need to individually administer those services, compared to a single large monolithic application. If these services are not automatically deployed, the administration of these multiple services will be a nightmare and could break the core benefit of microservices ꟷ agility. Make sure that you know what automation tools are available to you that will also support your microservices before making the decision to deploy them.
#4: Are microservices more complex?
Deploying multiple services is more challenging than deploying a single service. To achieve application service independence, a team must be enabled to cover the whole lifecycle of a microservice, which could require organizational changes, in addition to increased configuration management. For each microservice, you’ll need to create a dedicated build and delivery pipeline that is supported by fast, low-latency interconnections between each service.
#5: What is the fastest way to deploy microservices?
Microservices can be deployed faster in containers than on virtual machines (VMs). In fact, they can be deployed on demand without generating any unacceptable performance impact. Microservices and containers are an ideal match, given the heaviness of a VM (which has its own operating system) and the ability of modern applications to quickly spin-off and tear-down microservices.
#6: Do microservices increase user response time?
The more microservices you have, the greater chance your users will see a performance hit due to increased bandwidth demands caused by end-user calls. To improve performance, you’ll want to reduce the number of calls. Also, making HTTP requests (via a client API) and processing it (via Java API for RESTful Web Services or JAX-RS) between microservices is more laborious than doing an easier programmatic method call to a single monolithic application. You have to change all dependent services, especially when moving code between services. If a lot of services require real-time response time – such as banking – maybe it is best to keep an application monolithic, rather than breaking it into microservices.
#7: Are microservices reliable?
Microservices run in separated processes and communicate over the network via a dedicated mechanism (e.g., REST calls or messaging). However, a microservice is not available if the network is not available. HTTP requests or responses can also get lost – especially in comparison to a programmatic API call. You can deal with these issues by implementing approaches to handle those situations, or you may need to make your microservices more “resilient.” Proximate direct interconnection between microservices helps improve performance and reduces the risk of network failure, versus going over the public internet or virtual private networks.
But if you do experience a failure, you can take any of these steps to remediate it:
- Fall backs allow you to return a canned response or call a different service as a backup. You can also do a simplified calculation to recover the service. Bottom line: Think through the existing alternatives to help fulfill (or partially fulfill) the expected application service.
- Partial data validation enables you to pull out just the data that is needed if a service is not available and you cannot do a full data recovery. This means your application logic should be smart enough to work around the parts of the data model/response that are not really needed.
- Misbehaving services may fail in the middle of a transaction. Or a service may be inadvertently pounding away at other services with requests. A consuming service may also be experiencing high latency in the network (expect this in cloud deployments), and it may have timed-out and retried. If you build your services and interconnection between them to deal with these kinds of “unexpected” behaviors, they will be far more resilient. For example:
- Do not exchange messages between different systems as “deltas.” These are not idempotent messages, which allow certain operations to be applied multiple times without changing the result beyond the initial application.
- Employ infrastructure that can filter out duplicate requests between services to reduce the number of redundant messages going between services.
- Track unique identifiers in the messages received in your services and reject those that have been processed successfully.
- Leverage direct, high-bandwidth, low-latency connections between services on proximate systems and use network load-balancing.
Deploying microservices is not a panacea, it won’t solve all your enterprise IT needs. However, you can use microservices with other existing system and services architectures (e.g., containers, cloud), along with direct and secure interconnection between them, to deploy high-performance business applications. In the right situations, microservices can offer agility and speed in software development that can help companies advance and innovate in ways that weren’t possible before.
Learn more about directly and security interconnecting application development platforms by reading the IOA Playbook.
You also may want to read these blog articles about how we’ve leveraged microservices and containers to develop applications at Equinix: