Microservices is growing in popularity. Here, we break down what microservices are, give a microservices architecture example, and provide tips for utilizing microservices.
Microservices are a pattern, or architecture, that is focused around small, loosely-coupled services that comprise a greater application.
Microservices enable teams to create small, siloed pieces of functionality where each team owns their whole stack. They each do a little piece and then all those small pieces add up to be the whole.
One of the main benefits of a microservices architecture over a traditional monolith is that because you have small pieces, in terms of small problems being solved by small teams. Therefore, creating small, easy to understand solutions. It’s easy to replace them because you haven't dedicated years of work on a particular microservice so you can move from one technology to a newer one. If it's better, you can innovate faster, have much more flexibility. You're not locked into platforms for a decade at a time.
Another benefit of microservices architecture has to do with the reliability of the overall app as well as efficiency. If you think about a monolithic app, to scale up to meet additional user load or demand, you have to essentially clone the entire architecture. Another copy of the database, the webserver, the app server, all the functionality, all the business logic comes in one chunk. If you only need one little piece, like the zip code, lookup service has higher demand in a microservice architecture, you can scale up just that one. Look up with a monolith that you have to duplicate everything. So microservices are more efficient when it comes to hardware and resources. Scale-up just what you need as well as overall higher reliability.
Here's a microservices architecture example for an eCommerce website.
Let’s say you have a user interface on an eCommerce site. You have a zipcode lookup and you want it to automatically populate someone’s city and state when they type in a zip code. This is a small, easy to understand service. The microservice team that implements that service can choose any technology they like.
The team can build it with Java or with Nodejs or with PHP or with Python. There are many options your team can utilize, for instance, a typical SQL database, a no SQL database, a memory cache, and so on. Each team that develops a microservice has the same kind of choices, but they do need to have some commonality overall, which is where you start to think about things like a service mesh. A component, such as Istio, helps these microservices find and talk to each other.
You might ask the shipping microservice for a zip code. How do they do that? Do you hard code somewhere in that shipping service where these zip code lookup services? If you do, you’ve become more tightly coupled in the architecture. It looks more like a monolith. There's now more overhead and you can't easily change technologies.
With something like Istio, it gives the ability to have this infrastructure component, handle the services, communicating with each other, recording telemetry, data monitoring, data failovers, and different kinds of deployment strategies to test new versions. The individual developer of that one zip code lookup service doesn't have to care about any of that. It comes for free as part of this architecture.
One of the reasons enterprises typically choose to deploy microservices built on a primarily open source foundation is that on the microservice side of the world, the container orchestration tools: they are all led by open source packages. These are world-leading technologies and they all happen to be open source.
OpenLogic by Perforce has a long history of supporting complex environments. OpenLogic supports Docker, Kubernetes, Istio and Kafka. Our support team is comprised of enterprise architects with an average of 15 years’ experience in deep technical challenging products like Kubernetes, Istio, and more. For customers considering moving from traditional monolithic architecture to microservices, contact us so we can help from the start! OpenLogic can assist you in the process of figuring out which packages are best for you. The choice depends on what language you're using, what kind of experience you have with various platforms and traditional application servers for example, and databases can drive the need for different choices. Connect with us today to get started!
TALK TO AN EXPERT
This webinar gives tips on how to prime your organization for success when modernizing via a service mesh architecture.
CTO, Perforce Software
As the founder of OpenLogic, and now CTO at Perforce Software, Rod Cope provides technical vision and architectural leadership for the company’s globally distributed teams. Rod has over 25 years of experience in software development that spans a number of industries, including telecommunications, aerospace, healthcare, and manufacturing. Rod holds both Bachelor's and Master's degrees in Software Engineering from the University of Louisville.