Microservices 101

Few industries are subject to as much change as the IT industry. New tools and technologies arise every year. Some revolutionize the industry (now everyone is moving to the cloud) and some become outdated almost as soon as they arise (anyone remember the rush to get Glassed up?). It can be hard to distinguish beneficial new tools and technologies from the passing buzzwords. You may have heard the phrase “microservices” making its rounds lately, and asked yourself “what is a microservice, and do I need it?” I’d like to provide some clarity today by weighing in with my personal and company experience with it.

What are microservices?

Microservices architecture is a philosophical and architectural switch from traditional web service architecture. In a traditional web application, the entire system is a single entity containing multiple services. Many people when speaking of microservices call these legacy applications “monoliths,” but I hesitate to use the term since no one used the phrase until we started comparing them against microservices-focused applications. With microservices, the application is broken up into a collection of independent services. For example, let’s say you have an e-commerce web application. In it you have a user management service, inventory service, order service, payment service, etc. Each are built in the same program using the same language and have shared resources. If you built the same program with a focus on microservices, each of the above services is now compartmentalized in its own module and available via a RESTful API call. It is important to note that switching to microservices has slim to no impact on user experience for the application. The benefits are largely to your development and QA teams.

The Good

Microservices architecture provides many benefits, including:

Scalability: Each service can be scaled independently. If you have one service acting as a bottleneck for your application, you can apply targeted scaling to that service alone.
Isolation: Each service is isolated from the next. If you have a bug in your authentication service, you only need update the one service instead of your entire application.
Larger Toolkit: yYu are free to develop each service in whatever framework or language you like. You are not married to a single technology stack for the entire application.
CI/CD: Microservices make continuous integration much easier. You can publish updates only for the relevant new services instead of for the entire application. You can also test the updated services alone.

The Not-So-Good: Cost/Labor Breakdown

Breaking an application into multiple services requires a great deal of upfront costs and retraining. For these reasons, switching to microservices is not always strategically appropriate. Here’s a general litmus test you can apply to determine if it’s right for you: If your users number no more than a few thousand, and your application is not very complex; you may want to reconsider the conversion. Large, complex applications scaled to support high volumes of users stand to gain the most from microservices architecture.

Two tips to leave you with

To duplicate or not to duplicate?

If you’ve decided to implement microservices, you need to give a great deal of thought about your data hierarchy. When will it make more sense to have redundant replicated data, and when should you call other services for data? Following the example of an e-commerce site, let’s consider order history. You have one service for managing users and another for orders, and you want to see a large list of orders by user. Do you include redundant user data in the table for the order service to limit the number of calls made, or do you call both the user and order services to retrieve all relevant records? The answer will vary depending on many conditions.

Distribution

You should give real consideration into how to distribute your microservices. Should you use containerization, or should you deploy via virtual machine? There is a long-standing debate about the pros and cons of each. In a virtual machine environment, each service has its own OS and memory allocated. You need to have a separate license for each. In a container-based environment, such as Docker, you have a pool of containers sharing a single OS and memory. Containers are much lighter weight, as a result. In short, containers let you run more applications with the same resources.

Some argue that containers are more of a security vulnerability. If done right, they should still have the same attack surface as a virtual machine. It then becomes a debate on whether the potential to break out of a container and into the base OS is a greater risk than that of breaking out of a virtual machine and into the host machine. If using containers, you should take care to limit each container to one service. This will help provide code sanitization and reinforce the microservice philosophy of your architecture. My team usually recommends containerization to save time and money, but virtual machines work well for distribution if there are only a few services within the application.

If you’re interested in a deeper dive into the benefits or potential pitfalls associated with switching to microservices, my team would be happy to connect with you.