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.

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.”

Start the conversation

0 comments

Send me notifications when other members comment.

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.