More than one language for your application. For example, a backend in Golang, Ruby, PHP etc. and a Frontend Web App in React, Vue etc.
So, does that mean we should all just use JS or stick to server side rendering?
On a tangential note, I see this “just do it, don’t worry about the future” articles more and more often these days and I wouldn’t be surprised if that really is the message the wider developer community needs to hear in order to correct the current trends. However, I’m starting to feel like we need another correction to refine this message:
Sure, go ahead and do the simplest thing to kick things off, but don’t build layers on top of “just do it” layers! One thing that’s as dangerous as overengineering is engineering on top of underengineered infrastructure. Start with the simplest thing, but look for signs to recognize when to switch to a more sophisticated solution before you sink in resources working around the issues caused by the simple solution. As a senior developer, I always find myself in new projects where the technology sits on top of simple solutions surrounded by man-years of band-aid and at that point, migrating to a more appropriate base is a colossal task that never gets done and companies keep digging deeper by committing further to the band-aids.
I agree, that’s a weird thing to say about multiple languages. Almost every non-simple project I’ve ever worked on has used multiple languages, most often C++ and one or more of (Obj-C, JS, Python, Java, Lua, JS, Go, Nim…)
And especially in loosely-coupled (cross-process) server-side systems, you obviously use the best language for each job, and that depends heavily on what the best frameworks/libraries are and what languages those are written in. I’d be surprised if that ended up all being the same language for one system.
Not using a cloud service to host your app. Examples are Heroku, Vercel, Netlify and Fly.io. Most product teams will have over-architected their solution if they have to have an ops or infra team.
I have to disagree. If you are pre-revenue and will be there for a while, you can’t afford an accidental scale-up. Now maybe the bill can be kept small enough with care, but I look askance at anybody saying Just Use The Cloud without consideration for actual business needs.
More to the point of the entire article – Yes, Kubernetes is a sign you are dealing with a complicated deploy environment. Eventually your deployments get to the point of “I can’t spend person-hours on which service is on which machine” at which point something like K8s or K3s or Nomad will help. People get there at different times. If you have a lot of services and not many people, not because you built microservices but because you legitimately have a bunch of services, you might get there sooner than others.
The reason I think kubernetes isn’t necessarily premature optimization is the core important technology that every company no matter how small (*) should be using: Configuration Management. Configuration Management requires putting energy where your product is not. It’s a backend tooling factor that doesn’t matter to your customers. If you have a library in Python that you want to use and a library in C that you want to use, and a library in Javascript, and each library fills a unique niche in your product, you absolutely should use all three languages in your product. Not because it’s a good idea to go polyglot, but because you want to get the job and product out the door with the minimum amount of effort, and those libraries help you avoid that effort. Configuration management is somewhat like that. It takes effort, but it helps you avoid major classes of effort later. It allows you to orchestrate a single node, and if that node dies, you can be back running a few hours later.
Configuration management lets you say “I have a box over SSH. Now, I DECLARE IT HAS THIS SERVICE” and now it is so. This works for a good long while. It is important and not premature optimization.
K8s and friends allow you to say “I have a fleet and I declare somewhere in there, I have a service” as well as opening you to job management tools that you don’t necessarily have across multiple computers easily. All those cloud services have a solution that falls under “and friends,” allowing cloud providers to say “You have a service. It is running somewhere. The routes are there, and I don’t care where “there” is.
Now maybe you shouldn’t be running it. I personally never want to run k8s. Running it is too much wasted work (for me in my circumstances with my needs). But saying it’s a redflag on optimization is simply missing that it’s solving an entire class of problem so you never need to worry about it again.
(*): If you are a small company and have one computer and can afford to take a week to rebuild it, or have 3 (magic number) or fewer droplets, and can afford to take a week each if they get lost in a datacenter failing, then you don’t need to be running configuration management. But most of the time you want to build your thing, and configuration management helps you get the computers out of the way.
I am of the opinion that by now, Kubernetes is a very cheap innovation token. Most kubernetes providers are stable and easy to get started with. I know I would be able to deploy much quickly and a more reliable system through kubernetes than any other mean. Obviously, it’s always an “it depends” scenario where managing a fleet of nodes and container does not have the same requirements as running a Wordpress.
In my experience, Kubernetes is a substantial time investment and source of complexity for even the simplest of services. Hand-crafting a server from scratch is less effort at small scale.
Even in situations where it is the best tool for the job, it’s still a full-time job.
To each their experience! I’m running a cluster with a dozen nodes and two hundred containers on EKS and in the last year I would estimate at most 2 or 3 days worth of work that were caused by kubernetes (mostly upgrade and maintenance and a bug around volume provisioning). I would be interested to see how someone keeps itself busy for a full-time job running a cluster (that would not be a full-time job without kubernetes).
Fair enough, I am personally frustrated by this because we were previously using Heroku and it was just fine but now there’s this initiative to get everything on Kubernetes and it feels like I suddenly have to think about a tremendous amount of things that I didn’t previously.
To me, the sign of a good abstraction is exemplified by Larry Wall: make the easy jobs easy, without making the hard jobs impossible. Given the number of technologies you have to know in order to ship hello-world on k8s, I feel like it doesn’t live up to this.
I think that a cross-cloud migration is not the right time for learning Kubernetes. I have recently undertaken a similar migration, and it took me about two weeks to complete, working at a sedate pace and testing each of my steps incrementally. This wasn’t my first time with Kubernetes, so it was easy to work incrementally and build objects on top of each other.
For the specific case of Heroku, the order I might use is: Pod, Deployment, Service, HPA, External DNS (if desired), Ingress and TLS.
Hosted k8s is cheap in terms of effort to get started but like many managed offerings isn’t cheap in terms of money when you suddenly need to scale up.
I don’t think it’s particularly expensive either, especially compared to what the blog post would suggest (Heroku, fly.io, etc.) or the cost of computing resource you will be managing with kubernetes (EKS is 73 USD + 0.2-ish CPU requested per node?). I’m of the opinion that if someone get to a point where they need to scale-up and kubernetes cost are an issue, maybe there’s something wrong elsewhere.
I got confused recently trying to understand why folks assumed that you need k8s to run containers. This article covers some of my thinking in the topic but largely adds a broader take related to organizational focus.
So this is a cool question but kubernetes needs to run on something as well. Kubelet, or whatever other form of orchestration, can crash just as much as a container engine itself So either way you have the cluster management problem, so to speak. Unless using a cloud provider’s managed kubernetes service. In either case there is a huge difference between 30 and 500 servers.
I guess my concern is really around people absorbing the complexity of k8s when they don’t have a problem solved by k8s.
I guess my concern is really around people absorbing the complexity of k8s when they don’t have a problem solved by k8s.
Most people need to deal with configuration management, logging, service discovery, storage and deployment, though, in which case kubernetes is useful.
Kubernetes is, but so are most cloud services like Heroku if you want to do anything more serious than displaying stuff, as in demos or displaying things to potential customers. The reason is that while it goes okay for a bit your team will end up either spending time to reduce cost or looking for a different solutions. If you have some super rich investor or somehow unlimited flow or you are making enough money obviously ignore that, just like you can ignore premature optimization concern when you know you need to squeeze out performance in some situation.
Kubernetes is also a bad decision because it and its ecosystem are rapidly charging. People think about web frameworks constantly changing, but good luck in Kubernetes land. It doesn’t matter if the name stays the same when configuration, helm, operators and supporting tools change if you don’t want to run outdated software or your managed kubernetes drops support for a version.
And these things tend to come up at the worst possible time.
You could have just gotten a dedicated or virtual server, put configs into version control or use configuration management tools. All the things that kubernetes, etc solve really only become a problem when you to massively scale horizontally. A couple of thousand active userss are not massive.
Managing even a totally horrible setup on one or two machines tends to be a lot less time consuming than any size of kubernetes setup.
Also it tends to be a lot easier to replace such a setup than people think. While that might not have been the case if you were big and had complex software, today, especially if you already did the things you have to do anyways for any cloud or kubernetes based setup. If you take care of not having state all over the place, have configuration checked in some repo and have some sane backup just copying over all of that is as trivial as Kubernetis gets in a well setup state.
And if you do take care of state you also won’t have a problem if you do want to start using kubernetes, Nomad or any other solutions. Usually just copy your configs to the right place and it will work. So it isn’t like you lose something if you don’t do these things from the start. Switching versions tends to be the same work or even harder, especially when the people didn’t have experience.
Another benefit is that in emergencies as a small team you tend to be able to hack your way past an issue, and save your day or even the company. Not that you should rely on that , but having the option is better than not.
And I don’t mean just typical emergencies, but also ceasing opportunities. If you are not in that corset that a lot of modern practices for you into for good and right reasons you can make use of the flexibility you still have and actually “spend the remaining innovation tokens”, etc.
I’ve spent non-trivial amounts of time doing both, so I feel qualified to respond: no, Heroku will get you a lot farther than you give it credit.
The expense of each solution is different. Heroku is expensive up front and the expense is easily quantified. The expense of Kubernetes is the complexity.
Same here. In various companies, for over a decade now. Sure, expenses are quantified and I haven’t said otherwise.
Yes, it goes beyond demos, but it tends to get expensive more quickly than people realize. To be fair, that’s their whole business model, being just at the edge to make it justifiable to pay the price, but high costs lower your runway as a young company and it certainly does bite people that are in the early stage.
The point I am trying to make is that one should not blindly make oneself dependent on Heroku and make sure things stay easy to switch. That said I think with Heroku it’s relatively easy to not become locked-in so that’s a huge plus. I also took Heroku a bit as a placeholder for a class of products.
I however also think it’s a mistake to think that just because you are not going with these kinds of solutions you will be slow. I see people somehow thinking that once they don’t use these big solutions they will have all sorts of troubles, even though I think that the shift to seeing things as components where you have the application running as a “stateless” thing and state being stored in databases, as well as some more standardized ways of doing things that cloud providers, etc. enforced somehow go away, if you don’t use them. With most software being designed in such a way now automation, scaling out, etc. became a lot easier, even outside of typical cloud environments. So as a young startup it very much makes sense to consider these options. They might make a lot of sense.
Having modern practices isn’t dependent on running your application on AWS, etc. And then there is various implementations of self-hosted S3, etc., but that’s another topic.
So, does that mean we should all just use JS or stick to server side rendering?
On a tangential note, I see this “just do it, don’t worry about the future” articles more and more often these days and I wouldn’t be surprised if that really is the message the wider developer community needs to hear in order to correct the current trends. However, I’m starting to feel like we need another correction to refine this message:
Sure, go ahead and do the simplest thing to kick things off, but don’t build layers on top of “just do it” layers! One thing that’s as dangerous as overengineering is engineering on top of underengineered infrastructure. Start with the simplest thing, but look for signs to recognize when to switch to a more sophisticated solution before you sink in resources working around the issues caused by the simple solution. As a senior developer, I always find myself in new projects where the technology sits on top of simple solutions surrounded by man-years of band-aid and at that point, migrating to a more appropriate base is a colossal task that never gets done and companies keep digging deeper by committing further to the band-aids.
I agree, that’s a weird thing to say about multiple languages. Almost every non-simple project I’ve ever worked on has used multiple languages, most often C++ and one or more of (Obj-C, JS, Python, Java, Lua, JS, Go, Nim…)
And especially in loosely-coupled (cross-process) server-side systems, you obviously use the best language for each job, and that depends heavily on what the best frameworks/libraries are and what languages those are written in. I’d be surprised if that ended up all being the same language for one system.
I have to disagree. If you are pre-revenue and will be there for a while, you can’t afford an accidental scale-up. Now maybe the bill can be kept small enough with care, but I look askance at anybody saying Just Use The Cloud without consideration for actual business needs.
More to the point of the entire article – Yes, Kubernetes is a sign you are dealing with a complicated deploy environment. Eventually your deployments get to the point of “I can’t spend person-hours on which service is on which machine” at which point something like K8s or K3s or Nomad will help. People get there at different times. If you have a lot of services and not many people, not because you built microservices but because you legitimately have a bunch of services, you might get there sooner than others.
The reason I think kubernetes isn’t necessarily premature optimization is the core important technology that every company no matter how small (*) should be using: Configuration Management. Configuration Management requires putting energy where your product is not. It’s a backend tooling factor that doesn’t matter to your customers. If you have a library in Python that you want to use and a library in C that you want to use, and a library in Javascript, and each library fills a unique niche in your product, you absolutely should use all three languages in your product. Not because it’s a good idea to go polyglot, but because you want to get the job and product out the door with the minimum amount of effort, and those libraries help you avoid that effort. Configuration management is somewhat like that. It takes effort, but it helps you avoid major classes of effort later. It allows you to orchestrate a single node, and if that node dies, you can be back running a few hours later.
Configuration management lets you say “I have a box over SSH. Now, I DECLARE IT HAS THIS SERVICE” and now it is so. This works for a good long while. It is important and not premature optimization.
K8s and friends allow you to say “I have a fleet and I declare somewhere in there, I have a service” as well as opening you to job management tools that you don’t necessarily have across multiple computers easily. All those cloud services have a solution that falls under “and friends,” allowing cloud providers to say “You have a service. It is running somewhere. The routes are there, and I don’t care where “there” is.
Now maybe you shouldn’t be running it. I personally never want to run k8s. Running it is too much wasted work (for me in my circumstances with my needs). But saying it’s a redflag on optimization is simply missing that it’s solving an entire class of problem so you never need to worry about it again.
(*): If you are a small company and have one computer and can afford to take a week to rebuild it, or have 3 (magic number) or fewer droplets, and can afford to take a week each if they get lost in a datacenter failing, then you don’t need to be running configuration management. But most of the time you want to build your thing, and configuration management helps you get the computers out of the way.
This is the message of https://boringtechnology.club/; don’t spend your limited innovation tokens unnecessarily.
I am of the opinion that by now, Kubernetes is a very cheap innovation token. Most kubernetes providers are stable and easy to get started with. I know I would be able to deploy much quickly and a more reliable system through kubernetes than any other mean. Obviously, it’s always an “it depends” scenario where managing a fleet of nodes and container does not have the same requirements as running a Wordpress.
In my experience, Kubernetes is a substantial time investment and source of complexity for even the simplest of services. Hand-crafting a server from scratch is less effort at small scale.
Even in situations where it is the best tool for the job, it’s still a full-time job.
To each their experience! I’m running a cluster with a dozen nodes and two hundred containers on EKS and in the last year I would estimate at most 2 or 3 days worth of work that were caused by kubernetes (mostly upgrade and maintenance and a bug around volume provisioning). I would be interested to see how someone keeps itself busy for a full-time job running a cluster (that would not be a full-time job without kubernetes).
Fair enough, I am personally frustrated by this because we were previously using Heroku and it was just fine but now there’s this initiative to get everything on Kubernetes and it feels like I suddenly have to think about a tremendous amount of things that I didn’t previously.
To me, the sign of a good abstraction is exemplified by Larry Wall: make the easy jobs easy, without making the hard jobs impossible. Given the number of technologies you have to know in order to ship hello-world on k8s, I feel like it doesn’t live up to this.
I think that a cross-cloud migration is not the right time for learning Kubernetes. I have recently undertaken a similar migration, and it took me about two weeks to complete, working at a sedate pace and testing each of my steps incrementally. This wasn’t my first time with Kubernetes, so it was easy to work incrementally and build objects on top of each other.
For the specific case of Heroku, the order I might use is: Pod, Deployment, Service, HPA, External DNS (if desired), Ingress and TLS.
Hosted k8s is cheap in terms of effort to get started but like many managed offerings isn’t cheap in terms of money when you suddenly need to scale up.
I don’t think it’s particularly expensive either, especially compared to what the blog post would suggest (Heroku, fly.io, etc.) or the cost of computing resource you will be managing with kubernetes (EKS is 73 USD + 0.2-ish CPU requested per node?). I’m of the opinion that if someone get to a point where they need to scale-up and kubernetes cost are an issue, maybe there’s something wrong elsewhere.
I got confused recently trying to understand why folks assumed that you need k8s to run containers. This article covers some of my thinking in the topic but largely adds a broader take related to organizational focus.
How do you manage a fleet of 30 or 500 servers with docker? How do you perform restarts, deployments, etc? What happens if docker crashes?
So this is a cool question but kubernetes needs to run on something as well. Kubelet, or whatever other form of orchestration, can crash just as much as a container engine itself So either way you have the cluster management problem, so to speak. Unless using a cloud provider’s managed kubernetes service. In either case there is a huge difference between 30 and 500 servers.
I guess my concern is really around people absorbing the complexity of k8s when they don’t have a problem solved by k8s.
Most people need to deal with configuration management, logging, service discovery, storage and deployment, though, in which case kubernetes is useful.
Kubernetes is, but so are most cloud services like Heroku if you want to do anything more serious than displaying stuff, as in demos or displaying things to potential customers. The reason is that while it goes okay for a bit your team will end up either spending time to reduce cost or looking for a different solutions. If you have some super rich investor or somehow unlimited flow or you are making enough money obviously ignore that, just like you can ignore premature optimization concern when you know you need to squeeze out performance in some situation.
Kubernetes is also a bad decision because it and its ecosystem are rapidly charging. People think about web frameworks constantly changing, but good luck in Kubernetes land. It doesn’t matter if the name stays the same when configuration, helm, operators and supporting tools change if you don’t want to run outdated software or your managed kubernetes drops support for a version.
And these things tend to come up at the worst possible time.
You could have just gotten a dedicated or virtual server, put configs into version control or use configuration management tools. All the things that kubernetes, etc solve really only become a problem when you to massively scale horizontally. A couple of thousand active userss are not massive.
Managing even a totally horrible setup on one or two machines tends to be a lot less time consuming than any size of kubernetes setup.
Also it tends to be a lot easier to replace such a setup than people think. While that might not have been the case if you were big and had complex software, today, especially if you already did the things you have to do anyways for any cloud or kubernetes based setup. If you take care of not having state all over the place, have configuration checked in some repo and have some sane backup just copying over all of that is as trivial as Kubernetis gets in a well setup state.
And if you do take care of state you also won’t have a problem if you do want to start using kubernetes, Nomad or any other solutions. Usually just copy your configs to the right place and it will work. So it isn’t like you lose something if you don’t do these things from the start. Switching versions tends to be the same work or even harder, especially when the people didn’t have experience.
Another benefit is that in emergencies as a small team you tend to be able to hack your way past an issue, and save your day or even the company. Not that you should rely on that , but having the option is better than not.
And I don’t mean just typical emergencies, but also ceasing opportunities. If you are not in that corset that a lot of modern practices for you into for good and right reasons you can make use of the flexibility you still have and actually “spend the remaining innovation tokens”, etc.
I’ve spent non-trivial amounts of time doing both, so I feel qualified to respond: no, Heroku will get you a lot farther than you give it credit.
The expense of each solution is different. Heroku is expensive up front and the expense is easily quantified. The expense of Kubernetes is the complexity.
Same here. In various companies, for over a decade now. Sure, expenses are quantified and I haven’t said otherwise.
Yes, it goes beyond demos, but it tends to get expensive more quickly than people realize. To be fair, that’s their whole business model, being just at the edge to make it justifiable to pay the price, but high costs lower your runway as a young company and it certainly does bite people that are in the early stage.
The point I am trying to make is that one should not blindly make oneself dependent on Heroku and make sure things stay easy to switch. That said I think with Heroku it’s relatively easy to not become locked-in so that’s a huge plus. I also took Heroku a bit as a placeholder for a class of products.
I however also think it’s a mistake to think that just because you are not going with these kinds of solutions you will be slow. I see people somehow thinking that once they don’t use these big solutions they will have all sorts of troubles, even though I think that the shift to seeing things as components where you have the application running as a “stateless” thing and state being stored in databases, as well as some more standardized ways of doing things that cloud providers, etc. enforced somehow go away, if you don’t use them. With most software being designed in such a way now automation, scaling out, etc. became a lot easier, even outside of typical cloud environments. So as a young startup it very much makes sense to consider these options. They might make a lot of sense.
Having modern practices isn’t dependent on running your application on AWS, etc. And then there is various implementations of self-hosted S3, etc., but that’s another topic.