Breaking your monolith out to a distributed architecture is certainly a complex task. But having a solid perspective of what microservices are at a basic level can go a long way in terms of forming your migration and development strategies as you shift to this new architectural paradigm.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
We asked three software pros actively working with microservices to give us their simplest definition of microservices, and also to provide a little food for thought when it comes to microservice methodologies and planning. These engineers, architects and CTOs have all given presentations at software conferences about moving to microservices and have some fundamental advice for those getting started.
Randy Shoup, VP of engineering at StitchFix
“The ‘micro’ in microservices is more about the scope of the interface, and not about the amount of lines of code or how long it takes to write it. So, I think of it as a service that has a simple, well-defined interface, [and] that is composable, meaning that it’s sufficiently general that I can use the same [kinds of] microservices with lots of different clients to compose in lots of different ways.
And it is really just all the ideas that we have in software around building good classes, except at a slightly higher level of granularity. So, all the things we know about building software within a process. We build a class that is encapsulated, and the data is inside it. It’s got a simple interface, it’s easy to use and easy to understand. It’s exactly those design principles, just applied at the level of a process or a service.”
Gwen Shapira, system architect at Confluent
“Services, but very small. Basically it’s just small applications. And the name changed — 10 years ago, we probably called it service-oriented architecture, and now it’s microservices. And I feel like there is not a huge difference.
Basically, companies start out by writing their one big application. After a while, they grow to a thousand engineers, [and] you can’t have a thousand engineers who work in one setting. So they can start by breaking apart, and if you break it apart into large parts, you just call it service architecture. And if you break it apart a bit more, it’s microservices.
And it’s definitely possible to overdo your microservices. Someone mentioned having a service just responsible for joining things, which for me is maybe a bit too much as a microservice. But that’s kind of the direction it’s going in.
Basically, break things into very fine-grained work so that development teams can work independently and evolve the software faster for the company. It’s all about delivering value for the customer faster.”
Susanne Kaiser, CTO at JustSocial
“Microservices are independent, decoupled services taking care of a well-defined business function that you can easily change without affecting the entire system.
From a development team’s perspective, it means that you have teams taking care of specific set of microservices. And they are also taking care of business capabilities so that your team is based on business functions. And they can develop and deploy their services at different speeds, and can change different paths of the system independently, at the speed that they wish to release. So, for example, we have multiple teams working on different collaboration apps, and that’s reflected in our software architecture as independent services.”