Introduction to Microservices: What are Microservices?
A microservice architecture can beef up your team’s speed by adjusting how they design and ship code, and developers and business leaders can get ahead by implementing it inside their teams. The one-two punch of serverless and microservices combined is driving totally new types of applications and frameworks.
So what are microservices all about? The concept is based on a pretty simple idea: it sometimes makes sense to develop your applications as a lot of very small interlocking pieces instead of one giant whole. These components are developed and maintained separately from each other, so updates don’t require re-doing the entire codebase. Along with a few other design requirements, that’s the basic idea of microservices.
Understanding the “Traditional” Monolithic Model
Traditional application design is often called “monolithic” because the whole thing is developed in one piece. Even if the logic of the application is modular, it’s deployed as one group, like a Java application as a JAR file for example. Imagine if all of your notes from different college classes were in one long stream.
This type of code writing and deploying is convenient because it all happens in one spot, but it incurs significant technical debt over time. That’s because successful applications have a tendency of getting bigger and more complex as your company grows, and that makes it harder and harder to run.
For some insights into why and how a monolithic application can get confusing, consider this example from Chris Richardson: “I recently spoke to a developer who was writing a tool to analyze the dependencies between the thousands of JARs in their multi‑million line of code (LOC) application. I’m sure it took the concerted effort of a large number of developers over many years to create such a beast.”
There are a few reasons why this monolith eventually becomes so difficult to manage, including:
- The codebase is too big for any single developer to fully understand
- If the codebase is difficult to understand, changes made will often be detrimental
- Larger applications mean longer and longer deployment timeframes
- Agile frameworks often require multiple pushes to production each day, and re-deploying the entire monolith runs into time issues
Because of these and many other accompanying issues, a new way of developing applications is becoming popular. Microservices separates all of the major parts of this monolith from each other, untangling the codebase and drastically changing how developers can write and interact with it.
Service-Oriented Architecture (SOA) is used for applications composed of discrete and loosely connected agents that perform a function. SOA describes an application that can be built in such a way that its modules are seamlessly integrated and can therefore be easily reused. However, this type of architecture is very complex, sometimes sending over a million messages at a time, making it difficult to manage. SOA also often has higher response times and lower overall performance.
In contrast, microservices allows developers to build and manage software efficiently. It’s not only easy to work with during the design and build phase, but also performs with speed and efficiency once launched. Monolithic and SOA architectures both require systematic changes to be made by modifying the monolith. Microservices remove this issue, along with many others, by untangling the monolith so that changes can be made by simply creating a new service.
What Are Microservices?
In contrast with the monolith type application, here’s what an app developed with a microservices focus might look like:
Overall, it’s largely the same: you have a user interface, some functions, and a database. With microservices though, those functions (not literally functions, but functional parts of an application) are all separate. They communicate with the user interface, each other, and instances of the database.
A team designing a microservices architecture for their application will split all of the major functions of an application into independent services. Each independent service is usually packaged as an API so it can interact with the rest of the application elements.
In direct consonance with the problems outlined above, breaking down your application into bundles of microservices offers some key benefits:
- Simplify your application with well-defined boundaries for each piece of functionality
- Allow teams to work separately on independent parts of your application without the need for constant collaboration
- Microservices can be deployed, maintained, updated, and scaled independently of each other in a continuous fashion
It’s hard to overstate how large of a paradigm shift this new approach is. It totally flips around many of the challenges of traditional monolith deployment.
Microservices Examples and Business Use Cases
What is the use of microservices? A microservices-based architecture offers a lot of benefits in theory, but it’s difficult to make it work in practice. That’s why we’re still very much in the early development stages of this idea, and that applies even more strongly to larger companies.
But this isn’t entirely now. In fact, the concept of splitting applications into smaller interactive parts has actually been around as a programming paradigm for a while. One of the reasons why it’s taken this long for microservices to emerge as a legitimate alternative is simple: culture. Implementing this architecture isn’t just a technical decision: it’s about having the right teams in place, being comfortable using open source, and working in an organization that’s comfortable challenging the status quo in IT.
IT organizations are still figuring if they’re willing to make this shift. But in the meanwhile, those who do and find the right fit are reaping the benefits.
Challenges with Deploying Microservices
As with any design decision, there are drawbacks to a microservices architecture. The major issue is complexity––breaking up your codebase makes it easier to understand, but creates complications in orchestration. Microservices mean a distributed system, which comes with its own problems.
Your team is going to need to handle some new situations. For example, any individual microservice can fail at any point, just like a traditional software deployment. You need to write logic to deal with that. Another issue is database management––with the monolith there’s typically only one or a few databases to update, but with microservices there can be many. Managing data consistency across a distributed system can be a major challenge.
Finally, testing and deployment can become troublesome in a microservices-oriented architecture. If any services are dependent on others, you need to design a specific order for deployment and testing. Changes can impact multiple services in your application, and accounting for that is difficult.
Serverless, Microservices, and Containers
The shift towards microservices fits nicely with two other important trends in the deployment space: serverless and containers. Serverless is about abstracting the code around server side logic, and having a provider manage your infrastructure for you. Containers are all about bundling your code and dependencies into self-executing, independent packages.
Containers and microservices fit together because they have the same fundamental goal—package individual components as independent, responsive elements. Serverless empowers this architecture by focusing on functions as a service––now that your application pieces are packaged individually, deploying them as functions can make a lot of sense.
Why Microservices Are Killer for Machine Learning
As more machine learning goes into production, it’s becoming clearer that a microservices architecture can be a good fit for this kind of application. There are two major reasons why this is the case:
- After training your models, inference is usually stateless—since no data or state needs to be maintained, independent services work
- Machine learning is a compute-intensive process that often requires specialized hardware (like GPUs), and you don’t want that to be a core part of your server requirements
