What do Netflix, Uber, and Amazon all have in common? Well, apart from being some of the world’s most successful companies, they’re all using something called microservices. But what is a microservice? Are they related to containers? And where do Kubernetes fit it with all of this? If you’re not entirely sure, don’t worry! All will become clear in this post. Let’s dive in.
What is a microservice?
According to microservices.io, ‘microservices — also known as microservice architecture — are an architectural style that structures an application as a collection of services.’
It’s based on the Unix philosophy to ‘do one thing, and do it well.’ In this case, that one thing is building small, composable programs that work together to form an app, but that are also self-contained pieces of business functionality by themselves.
This differs from monolithic architecture, which is built as one large system that usually consists of one code-base. A developer will often deploy a monolith all at once, both front and end code together, regardless of changes. It’s easier to test and develop, but lacking in scalability. Which is where microservices come in.
Microservices are ideal for fast-growing startups, because they allow for rapid scalability — something Netflix, Amazon, and Uber all know a thing or two about. After all, you never know how big your company will become, and you don’t want technology to end up holding you back.
How do you define a microservice?
Bad news for the confused: There is no single definition for microservices. Overall, everyone agrees these are some of the defining characteristics:
- Easily maintainable
- Loosely coupled
- Deployable on their own
- Organized around business capabilities
Additionally, software developer and author Martin Fowler describes a microservices-based architecture as having the following additional features:
- Lends itself to continuous delivery. Microservices allow developers to create a change in one part of the app without having to rebuild and deploy the entire program: changes only impact a small number of services. Because of this, a microservice architecture makes it easier for the rapid and reliable delivery of large applications.
- Adheres to principles such as fine-grained components and business-driven development.
Microservices are a cloud-native architectural approach. Because each component can work as a standalone item, a manager can organize their developers into smaller teams that specialize in a specific service. These deployments are decoupled, so they can be scaled independently of each other, reducing the cost associated with scaling an entire app to adjust one feature.
For this reason, microservices make a more agile method of software development possible — namely, continuous integration and delivery.
What’s the difference between Service-Oriented Architecture (SOA) and Microservices?
Service-oriented architecture (SOA) utilizes reusable software components or services. Special code and data integrations required to execute a specific function make up each architecture. Microservices also consist of reusable, loosely coupled services. The main difference is, an entire enterprise will utilize SOAs, whereas microservices are usually for making individual apps more scalable.
Another difference is the number and classification of service types. Microservices have two: functional and infrastructure. SOAs have four: business, application, enterprise, and infrastructure services. Because of this, microservices are often thought of as a lighter version of SOA.
Here are some more differences between the two:
- Speed: microservices minimize sharing in favor of duplication, whereas SOAs share a common architecture, which simplifies development, but slows them down overall.
- Size: Microservices specialize in doing one thing well. SOAs can range from small up to enterprise-wide services.
- Communication: With microservices, developers create everything independently. With SOA, the services share a common comms mechanism.
Container vs VM: What’s the difference?
Microservices can run in containers, but they can also run as a Virtual Machine (VM). Conversely, you don’t have to use containers for microservices, but they are useful when it comes to deployment.
A VM is an operating system or app environment that is an emulation of a computer system. This means the user will have the same experience using a VM as they would using dedicated hardware. Each VM runs a guest operating system—with its own libraries, apps, and binaries—all of which can run on the same server.
VMs can also isolate apps, adding an extra layer of security and flexibility. When you add, update, or repair one app, the system remains unaffected. The main drawback is memory usage — which is large. This is where containers step in.
Containers have their own operating systems, file systems, CPU, memory, and process space — and you can decouple them from the main infrastructure. They have a much lower memory footprint due to their relaxed isolation properties.
What is Container as a Service (CaaS)?
Containerization is a big trend in developing right now. Container tools, like Kubernetes, are used to package services into containers that can then be rapidly deployed. In this way, they are complementary to microservices.
CaaS helps users build scalable containerized applications through on-premises data centers or the cloud. It’s easier to maintain separate microservices, but when it comes to network management, a container is useful for resource allocation and sharing.
What are the advantages of microservices?
- Independent ownership. Because microservices can operate as standalone items, individual teams can own each feature. This allows for faster delivery and deployment.
- Better scalability. Microservices can be deployed in clusters, which makes it easier for horizontal scaling across service boundaries. If one service is struggling, another one can be deployed to help out.
- Faster development cycles. Easier bugging and deployment both reduces cost and speeds things up
- A focus on quality. Being able to separate different business concerns into isolated microservices allows each team to focus on its own goal, free from distractions.
What are the disadvantages of microservices?
- Cost: Each microservices comes with its own hosting infrastructure, monitoring tools, testbook, and more.
- Complexity: It’s harder to main the network, because it needs more load balancing and has less fault tolerance.
- Organizational requirements: Because there are more teams working on separate things, there’s an added level of communication needed to keep things running smoothly.
Microservices as a concept is still relatively new, but it’s showing huge promise. To have the best chance of success with your team, start small. Then, as you gain confidence and experience, you’ll be able to scale up. It also means the process will be less complex — and if you do fail, there will be less risk.
The more flexible and user-friendly you can make the adoption process, the happier your dev team will be. Give them access to a project management framework that helps them test code and collaborate in real-time. Ideally, you should choose something that integrates with source code management tools (GitHub, Subversion) and has a good choice of plug-ins and extensions. You’ll also want it to be able to send out automatic notifications so developers can log in and pull tasks through, hear instant feedback, and access progress charts — all of which makes it easier to collaborate.
It’s never easy to grapple with new concepts — especially ones as complex as this. But, with good organization and plenty of open communication, your team can begin their microservices journey with confidence and a sense of purpose.