Have you ever seen this meme?
Yeah, sure you have. It’s one of the most popular memes when everything is blowing up in an environment, in your h...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
So very true. Not only for cloud and related tools, but for nearly everything in Dev/IT world. Let's go back to essentials:
Only start once we can answer these questions without reverting to some recent hype as the deciding factor.
Ah yes, do try out stuff. Hands-on. Actually use it. Build a prototype. Kick its tires, look inside. Don't ask your procurement department for help unless you know exactly what you need - or else spend valuable time & effort in a useless vendor shootout, and be prepared to solve politics instead of engineering a system that delivers value.
I agree with you 100%! Thanks for sharing your perspective.
Very true. TONS of cognative stress (no matter which way you shift it) on devs. Many tools in the API ecosystem. Ask the questions noted in this post before you embark on putting together an API Platform.
Agreed!
:)
I’ve never used Active Directory, but I’m very glad there are alternatives now, esp since (I assume?) I would have to maintain Windows servers
I believe that part of what caused the "too many tools" problem was the CNCF embracing everything.
For a long time Kubernetes was the only project under CNCF, and being under the foundation meant receiving money and attention, so (maybe intentionally, maybe not) Kubernetes became the only option for the workload orchestrator.
But then CNCF started receiving other projects, all of them tools that extend Kubernetes functionality, and most only work with Kubernetes, everyone wanted their own k8s "extension", and we got lots of projects with lots of duplicate functionality, with some hidden gems here and there.
And let's not forget that "cloud native" meaning "made for Kubernetes" was very likely a consequence of all this.
Too many chefs in the kitchen.
I totally see your viewpoint, however, I’d like you to think about building a car 🚘. You are going to need a tonne of various different components 🛞⚙️🔩🛢️ for this project. And we need a toolset 🧰🔧🪛as well.
For each of those components ⚙️and tools 🧰there are multiple vendors. It’s a maze 🤬😡out there. The supply chain ecosystem looks like a mess.
But here’s the thing, everything you need is free 🆓 and high performance 🏎️
If you know what type of car 🚙 🏎️🚛 you want and know how to build it 📖 💪👩🏻🔧.
Well then the CNCF ecosystem is the biggest parts store in the world.
one man's garbage is another man's treasure 😄
I honestly don't feel any confusion.
There are many products but all of them fit into just a few categories. For those of us who worked with self-managed (on-prem and remote VMs) and managed (App Service, Beanstalk) servers, containers (AKS/EKS, ECS/ACI), and serverless (Lambdas, Azure Functions) it's pretty easy to chose the right tool for a particular project.
We still have the same recommended DBs as we had 10 years ago: Postgres, SQL Server, MySql, Mongo, Redis. There are some new DBs like Cosmos and Dynamo, but they're easy to grasp if you've worked with DBs for a few years. There are also some specialized DBs for things like analytics, ML, online gaming, but not everyone will have to touch those directly.
We still have to collect Traces, Metrics, and Logs. Cloud made it super simple to enable all of those without even thinking about it. Modern SDKs adopted OpenTelemetry which allows to use a lot of data aggregators out of the box. It doesn't matter if it's New Relic, Splunk, Data Dog, Jaeger, App Insights, etc. Add a few commands to instrument your app and it just works.
CI/CD is simple - everything is integrated with everything. Plug a few commands and deploy your artifacts to any platform you need within seconds. Everything has built-in secret managers, integrations, packaged actions, telemetry, blue/green deployment capabilities, rollbacks, retries, audit, gated deployments, RBAC.
Modern IDEs have a lot of tools to deal with all of that out of the box. If anything, it has never been as easy as it is today to quickly develop a new system, roll it out to the end users, and scale from small to large with minimal efforts.
I understand that it's a lot for the new comers to comprehend but that's what the current senior+ engineers are for.
It really annoys me to see all the unecessary technical bloat people add just because its new and it will look good on their cv. They just end up adding technical debt and leaving someone else to deal with the problems they created when they leave.
Why do we need to know 10 js libraries that all do the same thing?
Its the same with cloud.
Agreed but I would also add that "what is your company already using" should factor heavily too. In the end of the day using a tool that other engineers in the business already know how to use is a big plus. As is "what tools can I easily hire more engineers to work with"
The comparison I would draw would be something like React. React is a pretty good tool for the Job but there are definitely cases where something else could be better (e.g. SolidJS, Svelte, Vue) but if those are less heavily adopted in the company/country then your baking in a need to train/upskill. Again not a deal breaker at all, but should factor in to your decision. As should "how hard is this to change"
This article says one thing. "Native-Cloud" is bad. Then it goes on to explain that it's a people issue, not a cloud issue. With engineer A making bad choices and not understanding the thing they chose to work with. It's not a bad thing to have 10 options. But it's up to the people to make sure the one, or combination of services they use will meet the requirements and are good choices. Having just one option doesn't make it better. If the engineers are confused, maybe they need simpler jobs.
I've been doing this over 20 years and was anti cloud. I was forced to move to 100% cloud and while I miss some of the on-prem control I had to resolve issues quicker in many cases, it's outweighed by the flexibility the cloud offers.
Not sure why this was hidden, I think this is a good comment.
Understanding this issue resonates with many, the Cloud Native Playground was created to assuage these exploration woes - play.meshery.io. The Cloud Native Playground is a collaborative, hosted environment where users can explore, experiment, and learn ALL CNCF projects in one unified space, where maintainers and ambassadors can readily espouse project configuration and deployment best practices... for free.
Confusion lives only in the small minds that have never really embraced cloud computing.
Are there a lot of moving parts yes because there always have been. The only difference between cloud and on prem is that on prem because you own the tin you are working with you can get away with being lazy and not fully scripting deployments and architecture.
In a pure cloud you have to expect things to fail and therefore rebuilding the infrastructure is key. Vendor disparity that is just noise that usually is exacerbated by company politics not by the technical matters... If the kitchen is too hot for you then...
It's not in Big Techs interest to keep tools the same. Far more money in constant change. For example I get a kick out of younger techies are looking at the new stuff like dynatrace in kubernetes to monitor rest services as if it's cutting edge brand new... What they don't know is WebMethods rest service ecosystem has been doing this for 25+ years... and doing it far better and providing a superior rest service eco system for 25 years. Once a tool becomes really good and stable for 5+years... Most large companies strategize purposefully to move away from them... More revenue...
Dynatrace is a bad product. Very slow, difficult to navigate, difficult to query, default views are not optimal and they don't let you customize them - load everything first and then filter - terrible. Trace viewer doesn't let you see the whole picture at once - they load only whatever fits on the screen and there is no way to export the whole thing to share with the teammates. And many other issues.
Michael, glad you wrote this it’s something a lot of people are afraid to put out because of how popular it is to be confused in today’s world.
I wrote about the future of compute and how we got there recently and touch on a lot of these points in my blog. (blog.jrlabs.io/posts/2024-02-19-wh...)
The entire idea of everything needing to be complex for the sake of complexity is really getting out of hand.
Every year I look at the renewed CNCF map, I feel like the volume of tools available grows between 50-100%.
I spend a lot of time thinking about this because this is the problem I'm trying to solve at my startup, Taloflow. Take a category like platform engineering, for example. It's in flux; few know how to really define it and what the solutions are.
It's inefficient that devs are spending weeks/months doing what's basically analyst research for their unique use case.
It's not a silver bullet but, KISS!