July 7 – Weekly Recap of All Things Site Reliability Engineering (SRE)

Posted on July 7, 2017 by Rob H

Welcome to the weekly post of the RackN blog recap of all things SRE. If you have any ideas for this recap or would like to include content please contact us at info@rackn.com or tweet Rob (@zehicle) or RackN (@rackngo)

SRE Items of the Week

Presidential Campaigns & Immutable Infrastructure by @danielbryantuk
https://www.infoq.com/news/2017/06/presidential-infrastructure

At QCon New York 2017 Michael Fisher presented “Presidential Campaigns & Immutable Infrastructure” and discussed the implementation and challenges of provisioning infrastructure for the Hillary for America (HFA) campaign that ran during the 2015-2016 US regional and national elections. Immutable infrastructure was key to the technical success of the campaign – the team moved quickly, but were resilient against failure for the majority of the time. It can take more effort to apply the principle of immutability to everything being deployed, but it is beneficial and developers “like the handshake between SRE and dev”. READ MORE

So you want to be a SRE? by Ingo Averdunk‏ @ingoa
https://hackernoon.com/so-you-want-to-be-an-sre-34e832357a8c

About 9 months ago I set out to leave my teaching career of six years to pursue a career as a Software Engineer. I attended a 3 month Programming Bootcamp called Hackbright Academy during which I not only learned the fundamentals of programming, but more importantly, the fundamentals of what type of work excites me. I realized that I loved design. I loved data-model design, user experience design, architectural design, system design… The list goes on, I love design. Because of this, I thought the best place for me would be as a Front End Engineer, boy was I wrong. READ MORE

LinkedIn Releases Open Source Tools
https://www.martechadvisor.com/news/search-social-ads/linkedin-releases-opensource-tools/

The social networking service for professionals, LinkedIn, has announced that it will be releasing a couple of key tools that will be available as open source projects. These have been primarily created to help businesses deal with issues regarding website outages. The new tools will also be enabling organizations to automatically connect with engineers whenever their applications fail. READ MORE
___________

Subscribe to our new daily DevOps, SRE, & Operations Newsletter https://paper.li/e-1498071701#/
_____________

UPCOMING EVENTS

Rob Hirschfeld and Greg Althaus are preparing for a series of upcoming events where they are speaking or just attending. If you are interested in meeting with them at these events please email info@rackn.com.

2017 New York Venture Summit – LINK

OTHER NEWSLETTERS

SRE Weekly (@SREWeekly) – Issue #79
The DevOps/WebOps Marketing Geek – LINK from @LukasHertig
Julie Evans Blog – LINK

June 30 – Weekly Recap of All Things Site Reliability Engineering (SRE)

Posted on June 30, 2017 by Rob H

SRE Items of the Week

Site Reliability Engineering at Dropbox with Tammy Butow @tammybutow

The mess and success of building open leadership (notes from Kubernetes Leadership Summit)
http://bit.ly/2tMTzEy

Three weeks ago, Kubernetes leaders met for a very busy day to reflect and plan how the community was being growing. I was humbled to be part of the Kubernetes Leadership Summit due to my work as the Cluster Ops SIG co-chair. READ MORE

Ops integration will be scary, proceed with haste
http://bit.ly/2u2Wfhq

As CEO of RackN, I talk to a lot of operations teams who have big aspirations for automation that are faltering due to internal resistance. Generally, we’re talking to the SREs on the team. Sadly, those SREs are often stymied by narrowly scoped teams and house-of-cards technical debt. READ MORE

The Case for Ops Engineering Pay Equity with Charity Majors
http://bit.ly/2tZBjYD

Charity Majors is one of my DevOps and SRE heroes* so it was great fun to be able to debate SRE with her at Gluecon this spring. Encouraged by Mike Maney to retell the story, we got to recapture our disagreement about “Is SRE is Good Term?” from the evening before. READ MORE

Datanauts #89 Dives Deep on SRE Approach and Urgency
http://bit.ly/2tqmbGl

In Datanauts 089, Chris Wahl and Ethan Banks help me break down the concepts from my “DevOps vs SRE vs Cloud Native” presentation from DevOpsDays Austin last spring. They do a great job exploring the tough topics and concepts from the presentation. It’s almost like an extended Q&A so you may want to review the slides or recording before diving into the podcast.

Here are my notes from the podcast READ MORE

5 Laws every aspiring Devops engineer should know by @ChrisShort
https://opensource.com/open-organization/17/5/5-devops-laws

“A good engineer is a lazy engineer,” some will say. And to a certain extent, it’s true: Laziness is a great quality if you’re automating repetitive tasks. But laziness flies in the face of learning new technologies and getting new work done. Somewhere between Junior Systems Administrator and Senior DevOps Engineer, laziness no longer becomes an advantage.

Let’s discuss the five laws aspiring DevOps engineers should follow if they want to become great DevOps engineers. READ MORE
___________

Subscribe to our new daily DevOps, SRE, & Operations Newsletter https://paper.li/e-1498071701#/
____________

UPCOMING EVENTS

2017 New York Venture Summit – LINK

OTHER NEWSLETTERS

SRE Weekly (@SREWeekly) – Issue #78
The DevOps/WebOps Marketing Geek – LINK from @LukasHertig
Julie Evans Blog – LINK

Datanauts #89 dives deep on SRE approach and urgency

Posted on June 29, 2017 by Rob H

TL;DR: SRE makes Ops more Dev like in critical ways like status equity and tooling approaches.

In Datanauts 089, Chris Wahl and Ethan Banks help me break down the concepts from my “DevOps vs SRE vs Cloud Native” presentation from DevOpsDays Austin last spring. They do a great job exploring the tough topics and concepts from the presentation. It’s almost like an extended Q&A so you may want to review the slides or recording before diving into the podcast.

Advanced Reading: my follow-up discussion on SRE with the Cloudcast team and my previous Datanauts podcast.

Here are my notes from the podcast:

01:00 “Doing infrastructure in a way that the robots can take over”
01:51 Video where Charity & Rob Debated the SRE term
02:00 History of SRE term from Google vs Sys Ops – if site was not up, money was not flowing. SRE culture fixed pay equity and career ladder, ops would have automation/dev time, dev on hooks for errors
03:00 Google took a systems approach with lots of time for automation and coding
03:20 Finding a 10x improvement in ops. Go buy the book.
04:00 SRE is a new definition of System Op
04:10 The S in could be “system” or physical location (not web site).
05:00 We’re seeing SRE teams showing up in companies of every size. Replacing DevOps teams (which is a good thing). Rob is hoping that SRE is replacing DevOps as a job title.
06:10 Don’t fall for a title change from Sys Op to SRE with actually getting the pay and authority
06:45 Ethan believes that SRE is transforming to have a broad set of responsibilities. Is just a new System Admin definition?
07:30 Rob things that the SRE expectation is for a much higher level of automation. There’s a big thinking shift.
08:00 SREs are still operators. You have to walk the walk to know how to run the system. Not developers who are writing the platform.
08:30 Chris asks about the Ops technical debt
09:00 We need to make Ops tooling “better enough” – we’re not solving this problem fast enough. We have to do a better job – Rob talks about the Wannacry event.
10:30 Chris asks how to fix this since complexity is increasing. Rob plugs Digital Rebar as a way to solve this.
11:00 People are excited about Digital Rebar but don’t have the time to fix the problem. They are running crisis to crisis so we never get to automation that actually improves things.
12:00 At best, Ops is invisible. SRE is different because it includes CI/CD with on going interactions. There’s a lot coming with immutable operating systems and constantly term.
13:00 The idea that a Linux system has been up for 10 years is an anti-pattern. Rob would rather have people say that none of their servers has been up for more than a week (because they are constantly refreshed)
13:19 Chris & Ethan – SECTION 1 REVIEW
- SRE is not new, it’s about moving into a proactive stance (automatically reacting)
- The power is the buy in so that Ops has ownership of the stack
15:00 SRE vs DevOps vs Cloud Native – not in conflict, but we love to create opposition
15:40 There is a difference, they are not interchangeable. SRE is a job title, DevOps is a process and Cloud Native is an architecture.
16:30 We need to resist that Cloud Native is a “new shiney” that replaces DevOps. We don’t have to take things away.
17:00 Lean is a process where we’re trying to shorten the flow from ideation to delivery. Read the Goal [links] and The Phoenix Project [links].
18:00 Bottlenecks (where we’ve added work or delays) really break our pipelines.
19:00 Ethan’s adds the insight: If you don’t have small steps then you don’t really understand your process
20:00 Platform as a Service is not really reducing complexity, we’re just hiding/abstracting it. That moves the complexity. We may hide it from developers but may be passing it to the operators.
21:00 Chris asks if this can be mapped to legacy? Rob agrees that it’s a legacy architectural choice that was made to reduce incremental risk. Today, we’re trying to make our risk into smaller steps which makes it so that we will have smaller but more frequent breaks.
22:40 The way we deliver systems is changing to require a much faster pace of taking changes
23:00 SREs are data driven so they can feed information back to devs. They can’t (shouldn’t) walk away from running systems. This is an investment requirement so we can create data.
24:00 We let a lot of problems lurk below the surface that eventually surface as a critical issue. Cannot let toothaches turn into abscesses. SREs should watch systems over time.
25:20 If you are running under performance in the cloud, then you are wasting money.
26:00 Cloud Native, an architecture? What is it? It means a ton of things. For this preso, Rob made it about 12 factor and API driven infrastructure.
26:50 “If you are not worried about rising debt then we are in trouble.” We need to root cause! If not, they snowball and operators are just running fire to fire. We need to stop having operators be heros / grenade divers because it’s an anti-pattern. Predictable systems do not create a lot of interrupts or crises. Operators should not be event driven.
28:40 Chris & Ethan – SECTION 2 REVIEW
- Chris: Being data driven combats complexity
- Ethan: Breaking down processes into smaller units reduces risk.
30:00 Cloud First is not Cloud Only. CNCF projects are not VM specific, they are about abstractions that help developers be more productive. Ideally, the abstractions remove infrastructure because developers don’t want to do any infrastructure. We should not are about which type of infrastructure we are using
31:30 The similarities between the concepts is in their common outcomes/values. Cloud First wants to be infrastructure agnostic.
32:30 Chris ask how important CI/CD should be. Are these still important in non-Cloud environments. Rob things that Cloud Native may “cloud wash” architectures that are really just as important in traditional infrastructure.
34:00 Cloud Native was a defensive architecture because early cloud was not very good. CI/CD pipelines would be considered best practices in regular manufacturing.
35:00 These ideas are really good manufacturing process applied back to IT. Thankfully, there’s really nothing unexpected from repeatable production.
36:30 Lesson: Pay Equity. Traditionally operators are not paid as well as developers and that means that we’re giving them less respect. HiPPO (highest paid person in organization) is a very real effect where you can create a respect gap.
38:00 Lesson: Disrupt Less. We love the idea of disruption but they are very expensive and disproportionately to the operators. Change for Developers may be small but have big impacts to operators. More disruptive changes actually slow down adoption because that slows down inertia. SREs should be able to push back to insist on migration paths.
40:00 Rob talks about how RedFish, while good to replace IPMI, will take long time before it. There are pros and cons.

Ops integration will be scary, proceed with haste!

Posted on June 29, 2017 by Rob H

TL;DR: Your own tool silos (and the teams supporting them) are blocking your progress.

Last week, I examined some of my DevOps scar tissue and tweeted: “consider, ops integration will be scary – you have to give up control of individual actions and silos. it’s hard to give up control”

The tweet seemed to strike a nerve with others because change and control are so often at war. It was based on a recurring theme that the RackN team sees from ops organizations: antibodies towards integrated solutions in favor of DIY projects combining disparate tools.

It makes sense to me that operators want a sense of control and ownership; however, those same motivations are counter to the automation imperative that should be driving them forward. Patching together a solution today is adding technical debt that becomes insurmountable when used in production.

This challenge is why so much DevOps content is targeted at organization culture instead of tools. While this is clearly the root, I also think that our tools are not designed to work together as a system. The fact that teams prefer it that was is as key part of the problem.

Let’s do ourselves a favor – let’s take the time to solve operations issues at the system level like we’ve been trying to do with Digital Rebar. We’ll all move faster together.

The Case for Ops Engineering Pay Equity w/ Charity Majors

Posted on June 28, 2017 by Rob H

TL;DR: Operators need pay/status equity to succeed.

Charity Majors is one of my DevOps and SRE heroes* so it was great fun to be able to debate SRE with her at Gluecon this spring. Encouraged by Mike Maney to retell the story, we got to recapture our disagreement about “Is SRE is Good Term?” from the evening before.

While it’s hard to fully recapture with adult beverages, we were able to recreate the key points.

First, we both strongly agree that we need status and pay equity for operators. That part of the SRE message is essential regardless of the name of the department.

Then it get’s more nuanced. Charity, whose more of a Silicon Valley insider, believes that SRE is tainted by the “Google for Everyone” cargo cult. She has trouble separating the term SRE from the specific Google practices that helped define it.

As someone who simply commutes to Silicon Valley, I do not see that bias in the discussions I’ve been having. I do agree that companies that try to simply copy Google (or other unicorns) in every way is a failure pattern.

Charity: “I don’t want get paid to keep someone else’s ~~shit~~ site alive”

I think Google did a good job with the book by defining the term for a broad audience. Charity believes this signals that SRE means you are working for a big org. Charity suggested several better alternatives, Operations Engineer. At the end, the danger seems to be when Dev and Ops create silos instead of collaborating.

Consensus: Job Title? Who cares. The need to to make operations more respected and equal.

What did you think of the video? How is your team defining Operations titles and teams?

(*) yes, I’m working on an actual list – stay tuned.

What makes ops hard? SRE/DevOps challenge & imperative [from Cloudcast 301]

Posted on June 27, 2017 by Rob H

TL;DR: Operators (DevOps & SREs) have a hard job, we need to make time and room for them to redefine their jobs in a much more productive way.

The Cloudcast.net by Brian Gracely and Aaron Delp brings deep experience and perspective into their discussions based on their impressive technology careers and understanding of the subject matter. Their podcasts go deep quickly with substantial questions that get to the heart of the issue. This was my third time on the show (previous notes).

In episode 301, we go deeply into the meaning and challenges for Site Reliability Engineering (SRE) functions. We also cover some popular technologies that are of general interest.

Author’s Note; For further information about SREs, listen to my discussion about “SRE vs DevOps vs Cloud Native” on the Datanauts podcast #89. (transcript pending)

Here are my notes from Cloudcast 301. with bold added for emphasis:

2:00 Rob defines SRE (more resources on RackN.com site).
- 2:30 Google’s SRE book gave a name, even changed the definition, to what I’ve been doing my whole career. Evolved name from being just about sites to a full system perspective.
- 3:30 SRE and DevOps are aligned at the core. While DevOps is about process and culture, SRE is more about the function and “factory.”
- 4:30 Developers don’t want to be shoving coal into the engine, but someone, SREs, have to make sure that everything keeps running

5:15 Brian asks about impedance mismatch between Dev and Ops. How do we fix that?

- 6:30 Rob talks about the crisis brewing for operations innovation gap (link). Digital Rebar is designed to create site-to-site automation so Operators can share repeatable best practices.
- 7:30 OpenStack ran aground because Operators because we never created a the practices that could be repeated. “Managed service as the required pattern is a failure of building good operational software.”
- 8:00 RackN decomposes operations into isolated units so that individual changes don’t break the software on top
9:20 Brian talks about the increasing rate of releases means that operations doesn’t have the skills to keep up with patching.

- 10:10 That’s “underlay automation” and even scarier because software is composited with all sorts of parts that have their own release cycles that are not synchronized.
- 11:30 We need to get system level patch/security.update hygiene to be automatic
- 12:20 This is really hard!
13:00 Brian asks what are the baby steps?

- 13:20 We have to find baby steps where there are nice clean boundaries at every layer from the very most basic. For RackN, that’s DHCP and PXE and then upto Kubernetes.
- 15:15 Rob rants that renaming Ops teams as SRE is a failure because SRE has objectives like job equity that need to be included.
- 16:00 Org silos get in the way of automation that have antibodies that make it difficult for SREs and DevOps to succeed.
- 17:10 Those people have to be empowered to make change
- 17:40 The existing tools must be pluggable or you are hurting operators. There’s really no true greenfield, so we help people by making things work in existing data centers.
- 19:00 Scripts may have technical debt but that does not mean they should just be disposed.
- 19:20 New and shiney does not equal better. For example, Container Linux (aka CoreOS) does not solve all problems.
- 20:10 We need to do better creating bridges between existing and new.
- 20:40 How do we make Day 2 compelling?
21:15 Brian asks about running OpenStack on Kubernetes.

- 22:00 Rob is a fan of Kubernetes on Metal, but really, we don’t want metal and vms to be different. That means that Kubernetes can be a universal underlay which is threatening to OpenStack.
- 23:00 This is no longer a JOKE: “Joint OpenStack Kubernetes Environments”
- 23:30 Running things on Kubernetes (or OpenStack) is great because the abstractions hide complexity of infrastructure; however, at the physical layer you need something that exposes that complexity (which is what RackN does).
25:00 Brian asks at what point do you need to get past the easy abstractions

- 25:30 You want to never care ever. But sometimes you need the information for special cases.
- 26:20 We don’t want to make the core APIs complex just to handle the special cases.
- 27:00 There’s still a class of people who need to care about hardware. These needs should not be embedded into the Kubernetes (or OpenStack) API.
28:00 Brian summarizes that we should not turn 1% use cases into complexity for everyone. We need to foster the skill of coding for operators

- 28:45 For SREs, turning Operators into coding & automation is essential. That’s a key point in the 50% programming statement for SREs.
- In the closing, Rob suggested checking out Digital Rebar Provision as a Cobbler replacement.

We’re very invested in talking about SRE and want to hear from you! How is your company transforming operations work to make it more sustainable, robust and human?We want to hear your stories and questions.

The mess and success of building open leadership (notes from Kubernetes Leadership Summit)

Posted on June 26, 2017 by Rob H

TL;DR: Working on building open governance that is both inclusive and able to make hard decisions.

building-joy-planning-plans Three weeks ago, Kubernetes leaders met for a very busy day to reflect and plan how the community was being growing. I was humbled to be part of the Kubernetes Leadership Summit due to my work as the Cluster Ops SIG co-chair. Please join us every other Thursday at 1 PT to share stories about running or planning to run Kubernetes.

This event had to thread a delicate balance for an open project: we needed to limit attendance to focus discussions while ensuring that the community was represented. Our notes (captured in Google Docs) are being transcribed to markdown here.

Here are some key topics that shaped the day from my perspective:

A consensus that core needed to focus on paying down debt and getting smaller. The core project is seen as a bottleneck to growth. The comes from number of people trying to interact in the repo and from having too much technical debt, As a group, we agreed that paying this debt was very important; however, we did not define or authorize specific action to address it. I felt that just acknowledging this focus by a show of hands was a positive action.
Moving forward on formation of a Steering Committee. The bootstrapping committee reviewed their Steering Committee proposal. The concepts here are to design a governing body that intentionally delegates their authority. I think it’s an interesting approach that will help to empower more people in the project. This design is different than a corporate board that’s focused on supervision. Here’s the draft document we reviewed as input into the next phase proposal.
Continue using SIGs to divide work. A consequence of the governance design is that we are (ab)using special interest groups (SIG) to organize the coding and feature work for Kubernetes. They also carry the load for releases, product management and operations. The push from the meeting was to have all SIGs with specific deliverables. I think that works well for some SIGs, but more user/operator focused groups (like Cluster Ops) will feel that it’s harder to find the right engagement models.

Overall, the event was very positive with lively group discussions. This group is focused on building Kubernetes, so there was very little vendor, marketing, user or operator focus. As the project grows, I believe these other focus areas will be important to manage. Likely, those concerns cannot be addressed until the Steering Committee is formed.

RackN is committed to helping make Kubernetes operable and improve the operator experience. I’m interested in hearing about your remote or local impressions of this event. What items should have gotten more discussion? What is the project missing?

June 23 – Weekly Recap of All Things Site Reliability Engineering (SRE)

Posted on June 23, 2017 by Rob H

SRE Items of the Week

Datanauts 089: SRE vs Cloud Native vs DevOps
http://bit.ly/2txPXWV

Rob Hirschfeld joins the Datanauts to talk about the term Site Reliability Engineer (SRE) and what it means for IT operations.

Rob explores how the SRE designation is an effort to put operations teams on a more equal footing with developers within an organization. Rob and the Datanauts also discuss how SREs line up with other industry trends such as the cloud native and DevOps movements. LISTEN HERE

Why Does DevOps Require a New Operating Model? By Mustafa Kapadia @MKapadiaTweets
https://devops.com/why-should-cios-redesign-their-organizations/

For many, redesigning the operating model is table stakes for a successful DevOps transformation. But have you ever wondered why? Popular wisdom will have you believe that the main reason for operating model redesign are to…

“Improve collaboration between business and IT”
“Realign metrics”
“Take full advantage of the new tools”
“And even jump start culture change”

While these are all good reasons, frankly they miss the point. Experience suggests there is a more practical reason – match ownership with desired output.

What do we mean by that? Well first, let’s look at how the current model works. READ MORE

What can developers learn from being on call? By Julia Evans @b0rk http://jvns.ca/blog/2017/06/18/operate-your-software/

We often talk about being on call as being a bad thing. For example, the night before I wrote this my phone woke me up in the middle of the night because something went wrong on a computer. That’s no fun! I was grumpy.

In this post, though, we’re going to talk about what you can learn from being on call and how it can make you a better software engineer!. And to learn from being on call you don’t necessarily need to get woken up in the middle of the night. By “being on call”, here, I mean “being responsible for your code when it breaks”. It could mean waking up to issues that happened overnight and needing to fix them during your workday! READ MORE

Kargo Ansible Playbooks foster Collaborative Kubernetes Ops
http://bit.ly/2qENw3I

Why Kargo?
Making Kubernetes operationally strong is a widely held priority and I track many deployment efforts around the project. The incubated Kargo project is of particular interest for me because it uses the popular Ansible toolset to build robust, upgradable clusters on both cloud and physical targets. I believe using tools familiar to operators grows our community.

We’re excited to see the breadth of platforms enabled by Kargo and how well it handles a wide range of options like integrating Ceph for StatefulSet persistence and Helm for easier application uploads. Those additions have allowed us to fully integrate the OpenStack Helm charts (demo video). READ MORE

newsletter

Subscribe to our new daily DevOps, SRE, & Operations Newsletter https://paper.li/e-1498071701#/

UPCOMING EVENTS

2017 New York Venture Summit – LINK

OTHER NEWSLETTERS

SRE Weekly (@SREWeekly) – Issue #77
The DevOps/WebOps Marketing Geek – LINK from @LukasHertig
Julie Evans Blog – LINK

June 16 – Weekly Recap of All Things Site Reliability Engineering (SRE)

Posted on June 16, 2017 by Rob H

SRE Items of the Week

The Cloudcast #301 – SRE and Infrastructure Operations
http://www.thecloudcast.net/2017/06/the-cloudcast-301-sre-and.html

Description: Brian talks with Rob Hirschfeld (@zehicle, Founder/CEO of @RackN) about the concepts of SRE (Site Reliability Engineering), the challenges of maintaining infrastructure software, emerging tools and the next-generation of operations.

Show Notes:

Topic 1 – Welcome back to the show. Let’s start by talking about the concept of SRE (Site Reliability Engineering). Give us the basics and maybe explain how it differs from what people define in DevOps.

Topic 2 – Application development has been moving faster for quite a while (agile development, etc.). But now infrastructure/operations teams have to deal with faster software – especially around updates (e.g. Kubernetes releases every 3 months). How are companies managing this?

Topic 3 – Given that this pace of operations change may not slow down, how do you think about the challenge in terms of process/operations versus technology/tools?

Topic 4 – What are some of the steps that companies take to better prepare for this type of operational model? Tools, process, skills, etc.

Topic 5 – Do you see SRE as being a progression for existing infrastructure/operations people, or is this more focused on sysadmins or developers that want to get away from building applications?

_____________

DevOps Enterprise Summit London: Tales of courage and community
https://techbeacon.com/devops-enterprise-summit-london-tales-courage-community

After spending two amazing days with 700 of my closest DevOps cohorts from Europe, the Middle East, Africa, and beyond, I learned all about the latest and greatest IT and technology transformation reports at the DevOps Enterprise Summit London. With substantial growth in attendance from the first year, in 2016, the buzz around the show was palpable. And, what a location! From the venue, the QEII Centre, we had 360-degree views of central London, from Big Ben to the London Eye and beyond.

Read more from Steve Brodie, CEO of Electric Cloud @stbrodie
_____________

.IO! .IO! It’s off to a Service Mesh you should go [Gluecon 2017 notes]
http://bit.ly/2rjw4We

Gluecon turned out to be all about a microservice concept called a “service mesh” which was being promoted by Buoyant with Linkerd and IBM/Google/Lyft with Istio. This class of services is a natural evolution of the rush to microservices and something that I’ve written microservice technical architecture on TheNewStack about in the past. READ MORE
_____________

A few things I’ve learned about Kubernetes
https://jvns.ca/blog/2017/06/04/learning-about-kubernetes/

I’ve been learning about Kubernetes at work recently. I only started seriously thinking about it maybe 6 months ago – my partner Kamal has been excited about Kubernetes for a few years (him: “julia! you can run programs without worrying what computers they run on! it is so cool!“, me: “I don’t get it, how is that even possible”), but I understand it a lot better now.

This isn’t a comprehensive explanation or anything, it’s some things I learned along the way that have helped me understand what’s going on.

Read more from Julia Evans @b0rk
_____________

UPCOMING EVENTS

2017 New York Venture Summit – LINK

OTHER NEWSLETTERS

SRE Weekly (@SREWeekly) – Issue #76
The DevOps/WebOps Marketing Geek – LINK from @LukasHertig
Julie Evans Blog – LINK

.IO! .IO! It’s off to a Service Mesh you should go [Gluecon 2017 notes]

Posted on June 6, 2017 by Rob H

TL;DR: If you are containerizing your applications, you need to be aware of this “service mesh” architectural pattern to help manage your services.

A service mesh is the result of having a dependency grid of microservices. Since we’ve decoupled the application internally, we’ve created coupling between the services. Hard coding those relationships causes serious failure risks so we need to have a service that intermediates the services. This pattern has been widely socialized with this zipkin graphic (Srdan Srepfler’s microservice anatomy presentation)

IMHO, it’s healthy to find service mesh architecturally scary.

One of the hardest things about scaling software is managing the dependency graph. This challenge is unavoidable from early days of Windows “DLL Hell” to the mixed joy/terror of working with Ruby Gem, Python Pip and Node.js NPM. We get tremendous acceleration from using external modules and services, but we also pay a price to manage those dependencies.

For microservice and Cloud Native designs, the service mesh is that dependency management price tag.

A service mesh is not just a service injected between services. It’s simplest function is to provide a reverse proxy so that multiple services can be consolidated under a single end-point. That quickly leads to needing load balancers, discovery and encrypted back-end communication. From there, we start thinking about circuit breaker patterns, advanced logging and A/B migrations. Another important consideration is that service meshes are for internal services and not end-user facing, that means layers of load balancers.

It’s easy to see how a service mesh becomes a very critical infrastructure component.

If you are working your way through containerization then these may seem like very advanced concepts that you can postpone learning. That blissful state will not last for long and I highly suggest being aware of the pattern before your development teams start writing their own versions of this complex abstraction layer. Don’t assume this is a development concern: the service mesh is deeply tied to infrastructure and operations.

The service mesh is one of those tricky dev/ops intersections and should be discussed jointly.

Has your team been working with a service mesh? We’d love to hear your stories about it!