Microservices, such as containers and web services, are all the rage. But are they the best fit for your company? Jack Wallen poses and answers the question.
Is this going to be yet another post, proclaiming the wide spectrum of benefits to be found in containers and various microservices? In a word: no. In fact, I’m going to, for once, take the opposite approach to this question and tell you why you probably do not need to deploy microservices.
Hear me out, before you roll your eyes and cast me aside.
I’ve spent the better part of four years exploring the likes of Docker, Kubernetes and other tools to deploy and manage microservices. Although I’ve never proclaimed myself a worthy contender to take over the task for an enterprise business, I know my way around the technology. Thus far, the conclusion I’ve drawn is fairly simple: microservices are not for everyone.
I’d go so far as to say that in the hands of the wrong company or admin, microservices will do more harm than good. Let me explain.
SEE: Top 5 programming languages data admins should know (free PDF) (TechRepublic)
The inherent challenges of microservices
If you’re a large enterprise company, chances are good you have made significant investments in your development teams. Those teams are also probably made up of some of the best talent in the country—or the world. You probably also have the resources to invest in a team specifically designed for microservices.
If that’s you, congratulations. The inherent challenges of microservices won’t stop you from moving forward. You have the budget and the developers to make it happen.
If that’s not you, look out. If you think those in-house developers are going to be able to, in the blink of an eye, make the shift to Kubernetes, you are in for an eye-opening surprise.
Although when microservices are done right, they are a godsend because they can:
Automatical scale to meet demand
Save you money
Offer your company unheard-of agility and stability
However, microservices are not easy to do right. Unless you do them with unusually high accuracy and skill level, those deployments are going to be seriously problematic.
Pods won’t communicate with one another
They’ll be far more costly than you expect
You’ll lose data
You’ll frustrate customers
Your developers will suffer burnout (after spending countless hours in deployment)
Your admins will spend too much time keeping those services running (and less time keeping end users working)
Your network will be ripe for hacking
Does that sound like a laundry list of issues you want to deal with?
The truth of the matter is, microservices are incredibly challenging to do correctly. The internet might seem to say otherwise. Fire up a Google search and you can read an endless stream of microservice success stories—companies who’ve saved thousands upon thousands of dollars and even rolled in automation to make things even easier.
What those stories don’t tell you is the countless hours their developers and admins have spent to reach that point, and the dollars they’ve had to spend to make it happen.
All the while, your smaller company could have successfully deployed a monolithic service, at a fraction of the cost and time, and enjoyed an equal amount of success.
Will it scale as quickly, easily and automatically as a microservice? No. Will it automatically heal itself like a microservice? Possibly. But you have to ask yourself, how wide and high does your company need to scale at the moment?
Naturally, you hope to grow. To stay competitive, every company must grow. This is where the rubber of truth meets the realistic road. How much growth do you expect in the coming months or years? If you believe that growth could be exponential in nature, then it might well be time for you to start planning on adding microservices to your IT palette. When you do that, you have to figure in the cost and staff to make it happen, because it is going to cost you. Either that or you have to pull a few of your developers aside and inform them they’re heading up a new team to prepare for the addition of container deployments.
They’ll need as much time as you can give them.
As I’ve said before, Kubernetes is hard. Sure, you can deploy a Kubernetes cluster in about 10 minutes, but the post-cluster learning curve is exceptionally high. To make matters worse, to get the most out of microservices, you’re going to need to adopt a DevOps workflow where developers and admins work together to deploy the technology.
The inherent cost of microservices
Everyone wants to tell you how much money they’ve saved using microservices. It makes sense. You’ve deployed a Kubernetes cluster on AWS that scales and heals automatically and finally gives you the uptime you’ve dreamed about.
The problem is, unless your developers have dotted every single i and crossed every t, you’re going to wind up paying more than you think. One missed i or t can cause a pod to gobble up resources faster than you can say, “Bottom line!”
Consider this: your developers have created a pod to be deployed to a Kubernetes cluster on AWS. The pod needs to be able to handle serious traffic, so they’ve made sure to configure something like this:
resources: requests: memory: 500M cpu: 5 limits: memory: 1000M cpu: 10
The above snippet would request 500 MB of memory and 5 CPU cores and would have a limit of 1,000 MB of memory and 10 CPU cores. For anyone that’s deployed a pod to Kubernetes, that’s madness, but it happens. Admins find their pods refuse to stay running, so they ramp up the resources to ensure it won’t crash. When that happens (and it does happen), it’ll cost you. Remember, services like AWS are pay for what you use. What happens if, all of a sudden, you have several containers in a pod that are draining your account of resources, all the while racking up charges on your account?
You might scoff, but it happens. I’ve heard it too many times from too many companies to think that it’s a myth or a one-off.
If you don’t have developers that are deeply entrenched with proper microservice configuration and deployment, you could wind up footing a bill that’s significantly more costly than had you gone with monolith applications deployed via virtual machines.
On the contrary, if you have a dedicated, well-versed team for the deployment of microservices, you can save money and enjoy scalability, agility and uptime you’ve never experienced. The key is training, knowledge and need.
If you truly need the level of scale offered by microservices, and you have a DevOps team with the training and knowledge to make it happen successfully, then, by all means, have at it.
On the other hand, if you don’t require that level of scale, or you’re not certain if your developers and admins can make it happen, then you need to think twice about diving into the waters of microservices. However, if you’re certain a level of growth is on the horizon (that can only be accommodated by containers and microservices), then it’s time you hit the meeting room and start planning for a future filled with Kubernetes, containers and web services.
When faced with the question, “Do you really need microservices?” know that only you can honestly know the answer. But in the answering, you must truly be honest with yourself, your business and the IT staff that keeps you up and running.
Subscribe to TechRepublic’s How To Make Tech Work on YouTube for all the latest tech advice for business pros from Jack Wallen.
Data Center Trends Newsletter
DevOps, virtualization, the hybrid cloud, storage, and operational efficiency are just some of the data center topics we’ll highlight.
Delivered Mondays and Wednesdays
How to become a database administrator: A cheat sheet (TechRepublic)
5 Linux server distributions you should be using (TechRepublic Premium)
DevOps: More must-read coverage (TechRepublic on Flipboard)