Profile picture
Liz Fong-Jones @lizthegrey
, 43 tweets, 15 min read Read on Twitter
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 #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
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Liz Fong-Jones
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($3.00/month or $30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!