Ok, so what are Microservices?
Microservices are not a new concept. They share many aspects of Service-Oriented Architecture (SOA) and Domain-Driven Design: breaking up the application into "services" that do one thing, defining well designed "contracts" or "interfaces" between services and controlling where business knowledge is within the application instead of spreading it around in code, stored procedures and configuration are just some of those shared concepts.
To that extent, Microservices have been around for a long time. What makes them new, is not their impact on the application, but how they change the operation side of running application stacks. Microservices take SOA further by wrapping each service in a single "container" that is built solely for that service's purposes and can operate independently of the other containers. In the new containerized world of infrastructure, these bundled services are often Linux Containers, like Docker.
Like any other technology, SOA has costs and benefits: SOA makes applications more modular and cleaner, more understandable and maintainable, easier to develop in larger teams and more testable. It also makes applications larger, can add a lot of boilerplate code to the codebase and more complex to configure.
Microservices share all of those, both costs and benefits and then add some other challenges of their own: running a multitude of services independently brings many operational challenges from traceability to logging and debugging as well as resource allocation across the cluster, not to mention the operational challenges of running an infrastructure like Kubernetes that can handle those Containers. After all, building and operating a Kubernetes cluster in production is not an easy feat and you don't need Kubernetes to run a single monolith application. Or do you?
For the past 5 years, Containers and Kubernetes have almost always been related or mentioned alongside Microservices. The conclusion for many of our customers and people I talk to at conferences is: we don't run Microservices so we can't benefit from Kubernetes. This is a logical conclusion based on the origins of Kubernetes and how the marketing of it has been, and while Kubernetes is the best system to manage a Microservices application stack, that doesn't mean it doesn't bring in huge benefits if you don't run Microservices on it. Benefits that can easily outweigh its costs.
Kubernetes without Microservices
First, let's see what Kubernetes brings to the table: The biggest benefit of running Kubernetes as the basis of your infrastructure is removing "snowflakes". In a non-Kubernetes infrastructure, servers or VM turn into snowflakes: they are all the same but also different. Servers that run your MySQL are different from those running your Redis and those running your Java API are different from those running your frontend Node.js web application. There are ways to make those snowflakes easier to manage for sure: Chef, Puppet, Ansible, and all other configuration management systems are parts of that toolset, but they just make building snowflakes easier, they don't turn them into identical servers.
Kubernetes, on the other hand, takes in your servers and turns them into uniform "nodes". You can take a node out and replace it with another one while the workload sitting on top of them can be your API, frontend or database, completely oblivious to the type of node they are running on. This has huge implications on many aspects of your operations: It makes applying security patches easier and more standard, leading your infrastructure to be more secure. It also increases your high availability by allowing you to swap faulty nodes with new ones or resizing small ones with bigger ones without the downtime and little impact.
Another major benefit of using Kubernetes is that it mostly forces any infrastructure change to be performed through configuration files that enforce and standardize the documentation of infrastrcuture. On top of that, using Kubernetes means running applications in containers which in turn means using files like Dockerfile to define the application's operational requirements.
None of these great benefits above have anything to do with Microservices or exclusively benefit large organizations.
They work to benefit both small and large teams with or without DevOps personnel. They don't require breaking up monoliths into Microservices and having to deal with the challenges that it brings about.
Microservices, like any other technology, can be beneficial for certain circumstances, depending on your requirements. Kubernetes is also the same: not all teams need to run on a Kubernetes cluster. But coupling these two together limits the scope of their usefulness and reduces the size of the applicable audience they can benefit enormously.
There are many small application development companies, running on reliable and tested technologies like Ruby on Rails or PHP that will benefit from improved security, higher availability, reduced DevOps spend and better documentation that Kubernetes can provide, without breaking up their apps into tens of Microservices. If you work in one of those companies, I urge you to take some time and try it out!