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 new pattern. Some people call it an architecture that turns traditional application deployment on its head. So instead of what we used to have is a three-tier type architecture or web server app server database that had all the functionality of an entire application in it. Instead, you're having teams create small pieces of functionality where each team owns their whole stack, meaning the UI, if there is any or if it's API only the data access, the business logic. 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 zipcode. 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
CTO, OpenLogic by Perforce
As founder and CTO of OpenLogic, Rod Cope drives the technology vision for OpenLogic and heads the product management organization. Rod has over 20 years of experience in software development spanning 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.