Account Share

 

Thread by @lizthegrey: "Next up at NYC: @bridgetkromhout on Clouds, Containers, and Kubernetes. Minnesota is one of the largest DevOps communities in th […]" #devopsdays

43 tweets
Next up at #devopsdays NYC: @bridgetkromhout on Clouds, Containers, and Kubernetes.
Minnesota is one of the largest DevOps communities in the world. 1000 people turn up to MSP #DevOpsDays, but only 300 to DevOpsDays NYC.
We heard some history and culture; this one was labeled as architecture in the overview, but ties into history and culture and "human spaces". #devopsdays
Let's talk about how all of this relates to you. We need to figure out how these things help us at work on Friday or Monday. #devopsdays
IT in the 1990s had battle lines. "there'll be a link in the show notes... oh, this is not a podcast." apple vs microsoft, open vs closed source. open source has won. #devopsdays
Microsoft is one of the largest contributors to open source on GitHub. Still haven't done any windows since joining. #devopsdays
Poll from @swardley: Meltdown and Spectre: AWS [ed: and Azure and GCP] instantly patched, but private clouds... all lagging. fixed "after heartbleed", itself not yet patched. #devopsdays
Same as you can't be surprised by Settlers of Catan pirates, you can't be surprised that disruption and change is coming to IT. #devopsdays
It's a fundamental shift in how information disseminates across our organizations. We don't send things up and down the flagpole any more, we use backchannels to actually get things done. #devopsdays
It's frustrating to put together IT infra based on the relationships we have with people in other organizations. [ed: SLOs SLOs SLOs APIs APIs APIs omg] #devopsdays
"We're building complex systems out of software *and* out of humans". Is this resume driven development? #devopsdays
People wind up left with complicated, hard to maintain things from people doing experiments and then abandoning them. #devopsdays
Only adopt things if your needs dictate them, don't do it based on what people are excited about. "What problem will this tech solve for you?" #devopsdays
Choose cloud because it's right for you, not just because it exists in the world. #devopsdays
Choose the right abstractions and places to move things into the cloud based on what makes it *different* from what you already have. #devopsdays
Have something you're trying to accomplish (e.g. API-driven infrastructure) that you can't do in-house, rather than just shiny things you're trying to get someone to fund. #devopsdays
Dramafever started running docker in production in october 2013 when Docker was very very new. Joined them in 2014. We did cool things with containers... #devopsdays
Solved problems with consistent deployments by using containers, got away from bespoke server configs. But didn't solve all of our problems. Also created problems for ourselves. #devopsdays
e.g. dependency version mismatches, lack of infinite scaling of databases. Lots of problems you won't necessarily consider if you say "we should docker all the dockers". #devopsdays
Containers aren't technically new (e.g. chroot, jails, zones), but weren't widely adopted. why? Docker made things more usable, accessible, and available for developers to use rather than being monopolized by "scary ops people". #devopsdays
Kubernetes: 2015 OSCON was the 1 year birthday of Kubernetes. but at 1 year, didn't yet resonate with the community. Problem of orchestrating containers using janky bash. #devopsdays
Lots of important pieces: orchestration, monitoring, logging, tracing, rpcs, discovery, runtimes, meshes... CNCF is a lot more than just orchestration. #devopsdays
Containers are a tool to help you with repeatability, not a goal. Be aware of the complexity of the ecosystem and ongoing work. #devopsdays
So, onto Kubernetes. show of hands. how many people have used it in production vs. played around with it? 1/3 have played with it, only a handful use it in prod. #devopsdays
"Computers are easy, people are hard" is catchy but false; "scalable fault-tolerant distsys requires eng effort to build and operate; and people are even harder than that"... is more accurate. #devopsdays
When we decide to move to microservices, we add more scalability, but we make things *harder* to use. Maybe you do need it, maybe you don't. Who will need to be retrained?
Who will resist? #devopsdays
Every proof of concept someone wants to put into your org: day 1 is going to be amazing, but what about day 2? [c.f. vendor demos]. At some point you have to redeploy or scale out or patch. #devopsdays
Peak planning [e.g. black friday or tax day] is hard. It's great if something works seamlessly, but it's essential for it to work on days 2 through 2005. #devopsdays
Ask how questions. How are we going to transition? [ed: and decommission the old thing]? How are we going to run it? We're just getting started when we stand it up for the first time. #devopsdays
For evaluating new tech, make sure that you understand the underlying technology. c.f. "kubernetes the hard way" by @kelseyhightower #devopsdays
Make sure you know what it's doing before you buy the packaged solution version that a vendor is selling you. #devopsdays
"You can have that war as to whether it's kube-control, kube-cuddle, but either way, it's a way of talking via the API to the Kubernetes master." #devopsdays
[ed: obligatory ref to ] #devopsdays
Don't let someone discourage you from your Kubernetes dreams because you're running in a private cloud or onprem. #devopsdays
Master's job is to schedule pods on the nodes that make sense. #devopsdays
You probably want to use fluentd or some other method of collecting logs as there's no default logging in Kubernetes happening in the kubelet for your apps. #devopsdays
"This looks like something I built once, except plus or minus a few components..." exactly, Kubernetes is trying to be unopinionated and allow you to flexibly do things in familiar ways. #devopsdays
Idea is to unify languages we use to talk about systems, and make sure people understand the common design patterns. #devopsdays
If you just want to use Kubernetes without worrying about the innards, you can use AKS, GKE, or EKS, etc. -- without having to build a Kubernetes cluster yourself. #devopsdays
Projects to watch in the space to help you avoid the "murder mystery" problem when debugging: @heptio @honeycombio @IstioMesh brigade.sh #devopsdays
Finally, important to explore stuff. Especially if you don't yolo it directly into production; it's safe to experiment with your nonprod environments to find things that will help you a lot. #devopsdays
Be settlers rather than pioneers; make things operable rather than just focusing on brand new and shiny [ed: anyone know a less colonialist phrasing of this idiom?] #devopsdays
Orchestration is only one part; there's a whole suite of techniques you need. Clouds are still computers, silos are for grain, and containers don't make you devops. [fin] #devopsdays
This content can be removed from Twitter at anytime, get a PDF archive by mail!
This is a Premium feature, you will be asked to pay 30$/year
for a one year Premium membership with unlimited archiving.
Don't miss anything from @lizthegrey,
subscribe and get alerts when a new unroll is available!
This is a Premium feature, you will be asked to pay 30$/year
for a one year Premium membership with unlimited subscriptions/alert.
Did Thread Reader help you today?
Support me: I'm a solo developer! Read more about the story
Become a 💎 Premium member ($30/year) and get exclusive features!
Too expensive?
Make a small donation instead. Buy me a 🍺 beer ($5) or help for the 🛠 server cost ($10):
Donate with 😘 Paypal or  Become a Patron 😍 on Patreon.com
Using crypto? You can help too!
Trending hashtags:
Did Thread Reader help you today?
Support me: I'm a solo developer! Read more about the story
Become a 💎 Premium member ($30/year) and get exclusive features!
Too expensive?
Make a small donation instead. Buy me a 🍺 beer ($5) or help for the 🛠 server cost ($10):
Donate with 😘 Paypal or  Become a Patron 😍 on Patreon.com
Using crypto? You can help too!