A question we have been asking ourselves a lot here at Buildly lately is are we doing microservices or are we just Cloud Native? And is there really a difference? Google seems to have an opinion that microservice architecture is almost required to use a cloud native architecture efficiently. That might be right, but I guess it depends on your definition of “micro”.

I’m certainly a fan of microservice architectures and I think we can all agree that they work best on something like the Google Cloud Platform, but I do have a problem with the term “micro”. Once you get into serverless architectures the term micro, for function driven and stateless architecture certainly fits, but when you need to build a service driven by business requirements and developers need to be able to build those models and relational dependencies as efficiently as possible, maybe micro isn’t the the way you should be thinking.

Maybe these container driven services are more business logic services, or logical services, or something close to that. I have called them logic modules in that past but I’m not sure that explained enough of what they were, certainly module implies modular and reusable, but I think we lose a bit of the right size or proportion that micro would give us.

Certainly reusable services makes sense to us in describing these services, but not every software development process needs to focus on reusability in code. Maybe they should, I know it’s a fundamental I have been taught since I started developing software, but some times businesses have a simple need and a simple monolithic like architecture fits that need much better, even though monolithic may not be entirely accurate in terms of the size of that service either. It’s not easy to argue the value of spending time on reusability to a manger or CEO who is only concerned with building one product. I think the answer here has to be to argue for best practices and standards, to show that smaller more modular bits of code, regardless of reuse, is easier to maintain, optimize and fix when the need arises. This also helps to make code faster to develop by making it easier to spread the workout among different teams and helping to reduce redundancy.

For now, maybe the best thing we can do is to make these terms a bit more synonymous, cloud native and microservice architectures work better together, maybe only work together. If we drop the term micro from the services we are building it doesn’t limit us as much and it gives us the ability to clearly separate these services based on business logic, developer responsibilities and logical functional separation and need for state management. Some have gone back to the Service Oriented Architecture term, and while I have always like that approach it seems like a historically loaded term now and a step back. I always seem to come back to logical services or logic driven services.

Maybe in the end we are bridging some of these gaps between object oriented and functional programming as well, by focusing less on state and more on the structure and execution. Either way it can’t hurt to evaluate these practices to find ways to optimize. In the end these are all just terms, and it’s more about the approach to me, but I guess we need a precise way to communicate it. For now I guess we will stick with logical services, and just explain the difference.

If you’re curious we have put together an introduction on how we mange these services with our gateway functionality with our cloud native services and patterns, and will soon start adding to that with logical separation of services and some ideas on how we can standardize around models.