31–40 of 242 posts
Earlier quoted context omitted.
Microservices failure stories? “All of them. The End”
I'm not convinced all microservices ventures are failures. Having worked in the space a bit as a founder/CTO of a vendor in that space I've just seen many examples of misguided attempts due to fashion / CV-driven development / hype driven development. The pattern is valid, just not for everyone at every time.
I'd be interested in a related "microservices failure stories". Must be a big overlap with this.
Microservices failure stories? “All of them. The End”
To succeed, the ratio has to make sense. We had more than 2,000 engineers with fewer than a few hundred services. So, of course, it made perfect sense.
I've also seen a startup where it had 30 people and used the micro-service architecture. That didn't work very well. To make it worse, they used Node.js. It's like using Micro service wasn't difficult enough... they had to go with a dynamic-typed language.
Dang. I wish I had my SRE Wiki up and running already, or I'd add a "public postmortems" section.
1) no matter what I think I know, there's too many dark corners to create an adequate course
2) K8S is such a dumpster fire that I shouldn't encourage others
3) there's a hell of an opportunity here
Thoughts? Worth pursuing? Anything in particular that should be included that usually isn't in this kind of training?
I've started the planning phase of a Kubernetes course, geared toward developers more so than the enterprise gatekeepers. As I read stories like these, I jump between different thoughts and feelings: 1) no matter what I think I know, there's too many dark corners to create an adequate course 2) K8S is such a dumpster fire that I shouldn't encourage others 3) there's a hell of an opportunity here Thoughts? Worth pursu…
I've started the planning phase of a Kubernetes course, geared toward developers more so than the enterprise gatekeepers. As I read stories like these, I jump between different thoughts and feelings: 1) no matter what I think I know, there's too many dark corners to create an adequate course 2) K8S is such a dumpster fire that I shouldn't encourage others 3) there's a hell of an opportunity here Thoughts? Worth pursu…
Earlier quoted context omitted.
Microservices failure stories? “All of them. The End”
I'm consulting on a micro services back end right now with mostly prior experience with monoliths. What is the selling point that drives companies down this direction? It's insane, and my client keeps trying to hire new developers and bring on more consultants to build this thing, but the amount of knowledge required is more than any one person can handle. I have similar issues with their choice of db (nosql) and its…
Make sure you have a true service delivery and service management pipeline in place where it is real easy for dev and ops to deploy and decommission services.
Service metadata is key in my experience. Not too much though, just enough (such as service owner, deployment scopes, a release database, etc...). Nothing gets deployed without this metadata present, and make sure to automate the creation and keeping of these records.
Make sure convention before configuration applies, in most cases this is doable.
This stuff, in my experience, takes somewhere 6-12 months to put into place, including the actual automations/orchestration (be it the hashicorp stack, kubernetes, dc/os, triton, whatever). Do not even think about starting to move to prod before everyone have agreed upon the conventions and operational situation surrounding the stack and services.
Other than this, it's just code and integrations. Business logic. =)
In my last project we moved from 0 to 200 fully managed microservices using the hashicorp stack (plus a bunch of other stuff and homegrown things as well such as service metadata and release database/apis) and the biggest challenge was having everyone agree on the conventions.
Convincing the developers that this type of house-keeping will be necessary, perhaps not today, or next month, but down the line took a few months. In the end it was a massive success that really accelerated the way we could deliver value to the business.
When it comes to the data and ETL part you get a lot for free if the above is done decently. From my perspective the data scientists and ML guys need this stuff as well to be able to deploy and modify ETL flows and data pipelines at will. They'll most likely want to deploy some python, R and/or shiny apps as well! =)
They (can) benefit greatly from getting integrated in the same automations
Selling points achieved in above mentioned "transformation"/project:
- 14.000 production deployments with 45 devs and 3 "ops" guys (dev, ops, devops?)" in about a year. ("But why!?" someone will ask! And I'll be happy to respond.)
- Things started to happen, such as "could we just not provide this [insert awesome thing] to end users?" And what would have taken 6 months before could be pushed to canary days or even hours later.
- One specific feature I can think about increased revenue with more than a million dollars per month, and it took one of the teams exactly two days to build and release.
Granted, this was within a multibillion turnaround enterprise.
Most businesses would benefit from this transformation, but it requires a blend of people and technology that probably is difficult to attain outside the proper "tech" industry.
And my experience from within "small" tech is that focus sometimes is, understandably so, not situated around what I call systems management and service delivery.
Phew, that went on... sorry! =)
Having used Docker Compose/Swarm for last two years, I remember having problems with them twice. One of which was an MTU setting which I didn't really understand why, but overall I was relatively happy with them. Since Kubernetes seems to have won, I decided to learn it but got some disappointments. The first disappointment is setting up a local development environment. I failed to get minikube running on a Macbook A…
Out of curiosity, why do you need RHEL or subscription from Canonical for the production Kubernetes setup? What's wrong with plain Ubuntu or CentOS?
Dang. I wish I had my SRE Wiki up and running already, or I'd add a "public postmortems" section.
Just put it on Github like this and the Serverless one I also created after I saw this.
Having used Docker Compose/Swarm for last two years, I remember having problems with them twice. One of which was an MTU setting which I didn't really understand why, but overall I was relatively happy with them. Since Kubernetes seems to have won, I decided to learn it but got some disappointments. The first disappointment is setting up a local development environment. I failed to get minikube running on a Macbook A…
I think you might have misunderstood that page. The standard and universal way to deploy Kubernetes on to either your own bare metal or any cloud provider is to use kubeadm. However, if you would like a simpler and more automated solution and/or one backed by a vendor, you are welcome to pick any of the hosted platforms, distributions, or installers. CNCF has certified 70 conformant solutions: https://www.cncf.io/certification/software-conformance/
> Even if I never moved out of the big 3 (AWS/Azure/GCloud), the migration process could be painful since their Kubernetes may introduce further lock-ins for logging, monitoring, and so on.
If you choose open source solutions for logging and monitoring like Fluentd and Prometheus, then you can avoid locking into anyone's value added services and remain completely portable. If you decide to go with a vendor's solution, you may trade convenience for higher switching costs.
[1]: https://kubernetes.io/docs/setup/pick-right-solution/
Disclosure: I'm executive director of CNCF and run the conformance program.