Categories
All Cloud Computing CTO/CIO Devops

What does DEV OPS mean?

via GIPHY

I was recently interviewed by Victor Farcic. He asked me a lot of interesting questions.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

One really struck me that I thought was important, about the whole devops movement.

How do you define devops

Viktor Farcic: Moving on to a more general subject, how would you define DevOps? I’ve gotten a different answer from every single person I’ve asked.

Sean Hull: I have a lot of opinions about it actually. I wrote an article on my blog a few years ago called The Four-Letter Word Dividing Dev and Ops, with the implication being that the four-letter word might be a swear word, akin to the development team swearing at the operations team, and the operations team swearing at the development team. But the four-letter word I was referring to was “risk.”

Related: Why generalists are better at scaling the web

To summarize my article, in my view the development and the operations teams of old were separate silos in business, and they had very different mandates. Developers are tasked with writing code to build a product and to answer the needs of the customers, while directly building change into and facilitating a more sophisticated product. So, their thinking from day to day is about change and answering the requirements of the products team.
On the other hand, the operations team’s mandate is stability. It’s, “I don’t want these systems going down at 2:00 a.m.” So, over the long term, the operations teams are thinking about being as conservative as possible and having fewer moving parts, less code, and less new technologies. The simpler your stack is, the more reliable it is and the more robust and less likely it is to fail. I think the traditional reason why developers and operations teams were separated into silos was because of those two very different mandates.

Also: Walking the delicate balance of transparency

They’re two different ways of prioritizing your work and your priorities when you think about the business and the technology. However, the downside was that those teams didn’t really communicate very well, and they were often at each other’s throats, pushing each other in opposite directions. But to answer your question, “what is DevOps?” I think of DevOps as a cultural movement that has made efforts to allow those teams to communicate better, and that’s a really good thing.

Read: One time in 2013 I had to take the fall

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Scalability Startups

What Matt Ranney learned scaling Uber to 1000 services

via GIPHY

I was recently watching Matt Ranney’s 2016 talk from GOTO conference. He’s an excellent speaker, not least because of his formidable experience at the helm of Uber.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

Jump to 11:45 to start out…

1. What’s the cost of many languages

As they embraced microservices, they discovered surprising problems around having so many languages.

For example it became hard to share code and furthermore it became hard to move between teems.

The upshot is that the fragmentation of languages siloed teams, and built up tribes around those languages, and expertise or interest in them.

Related: How can we keep cloud architectures simple

2. What’s the cost of using RPC for everything

In the microservices world, everything becomes a remote procedure call. For starters there are problems with HTTP and related semantics.

Also there are challenges with JSON. Since there aren’t any types, you don’t have a schema to lock you into formats. So you get weird behaviors down the line.

The upshot: Servers are not browsers. Indeed. Function calls are wayyyy better *within* a datacenter. That’s because you control both servers, so you can tune accordingingly.

Also: What hidden things does a deposit reveal?

3. Tuning across languages can be very challenging

Different languages have different tools available. Can your favorite tool work across all the languages you’ve decided to support in your microservices?

Even though you’re going to go with microservices, think about standardizing across those services. Use tools that work on all of them. And when building your services, make sure it outputs the same dashboard metrics.

Read: Can communication mixups sour an engagement?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters

Categories
All Consulting CTO/CIO

Can humility help engagements succeed?

via GIPHY

I was reading this article on Vox recently titled Intellectual Humility: the importance of knowing you might be wrong.

Join 35,000 others and follow Sean Hull on twitter @hullsean.

It caught my attention, and I think we can expand on it a bit. Here are my thoughts.

1. Admitting when you’re wrong

Of course we’ve all had moments when we’re wrong. We make a proclamation, which turns out wrong. We measure something incorrectly. Or we forecast imprecisely.

It is hard to stand on the stage. The spotlight is on you. And when you do that you can be the object of criticism, and speculation. Just like everyone you may make mistakes, but when the spotlight is on you, it can weigh heavier.

That is exactly the time to be a bit humble, acknowledge your thought process, and where you went wrong. By standing up and admitting your mixup, you will come out the other side stronger.

Related: How can we keep cloud architectures simple

2. Admitting you might be wrong

This can be harder. As engineers we like to problem solve. We spend years exploring math & science, looking for the “truth”. The more one searches for it thought, sometimes the more illusive it can be.

Measurements are never exact. And theories and architectures often fail in the face of real world traffic. Applications fail. Servers fail. Outages happen. Customers especially paying ones will inevitably get angry, and this can backfire onto you.

Be prepared for the real world. It gets messy.

Also: What hidden things does a deposit reveal?

3. Allowing space for others to be wrong

This is a tricky one. You may know what others don’t, but it may take finesse to share that truth. You may have to sell your perspective, even while another perspective may be measurably wrong.

Be prepared to sometimes let things break a little. As hard as this is, it may allow for others to learn.

Like immunizing, sometimes failure can teach what words cannot.

Read: Can communication mixups sour an engagement?

Get more. Grab our exclusive monthly Scalable Startups. We share tips and special content. Our latest Why I don’t work with recruiters