4 years back, at the DevOpsDays Rockies, Dave Hahn (Senior Engineer in Netflix’s Operations and Reliability Engineering team) spoke about how Netflix approaches DevOPS (watch the whole presentation here).
Netflix, as one of the largest data and telemetry company, which in plain english means: streams videos over the internet, admits that they really don’t think about DevOPS. At all. Dave says “We hire smart people and get out of their way”, which I think it’s the best way to describe DevOPS. As a problem solving, pain releaser cell inside your organization.
"CDNs can be expensive,” he says "they have requirements around business processes. Any time they have to place a cache somewhere, whether is a data center or an ajax or embedded in a network, they have to have some kind of profit model associated with the placement of that cache. Unless you re on a very large network, they can’t make as much investment in the caching infrastructure”.
Consequently Netflix can't put as much netflix (read as noun) out there. so what do you do? You start building your own, says Dave.
And they do that mainly through Amazon Web Services and Netflix Open Connect CDN, which means Netflix takes their own caching machines and can go on and approach any ISP. The ISP gets a stack of caching equipment for free from the media services provider (read: Netflix) that they put inside their network. It’s a win-win situation for everyone involved (the ISP, Netflix and the consumer). The users get content closer to them, the ISP gets transit costs back.
But let’s look at it from a very objective, factual perspective. What is Netflix? It is basically a large micro services infrastructure ( try not to be affected by the apparent oxymoron). As Dave said at the DevOpsDays Rockies, Netflix is made up of :
hundreds of micro services
thousands of daily production changes
tens of thousands of virtual instances
hundreds of thousands of customer interactions
millions of customers (81.5 mil, globally in 2018)
billions of time series metrics (2.5 bil/minute that are delivered, processed and stored)
tens of billions of hours streams every quarter;
It kind of looks like this:
Netflix does all of the above with tens of operations engineers and no NOCs.
Plus, they don't have data centers anymore , as they started the transition in 2010 and 6 years later they were completely cloud based.
I think this case right here perfectly describes how DevOPS can do most of the pushing and pulling, in a very safe, very efficient manner.
But what would a DevOPS team bring to YOUR company? you ask.
DevOPS as a Service
DevOPS. The child prodigy of the past decade. It’s collaborative, it’s agile, it’s efficient. Does the job and deserves the hype.
"You’ll hear talk of "squads," "chapters" and "tribes” as different flavors of “agile” says Nigel Davis, (contributing writer of Forbes online) adding further the words of Justin R., vice president of digital transformation agency SPR, who [believes there is no "after agile." He thinks the trends we’re seeing now–like DevOps, Continuous Delivery and Lean–are all extensions of it. ]
As companies strive to meet increasingly higher expectations to deploy and ultimately go faster to market or simply stay responsive to customer interactions, DevOPS as part of the effort of achieving all of the above, as a practice, will not go away any time soon.
The need to innovate at a high enough pace to penetrate or simply remain relevant inside the market is proven to be held back, more often than not, by a set of heterogeneous count of collaterals. All of which, or at least a big portion of them, DevOps is planning to solve and is actively doing so.
Adopting DevOPS
Adopting devops requires new tools and new skills, but perhaps more importantly devops requires a whole new mindset. It is more of a shift in culture than technology.
Simply put it’s the opposite of "every man for himself".
Devops focus is in one word: automation. Automation in terms of code testing, infrastructure, workflows, following the “automate everything” optics. Deployments are naturally faster and more frequent. Consequently, this reflects positively in any business model, reducing the probability of bottlenecks to occur, ultimately solving problems.
So, again, in plain english, the practice of DevOPS could be summarized as:
automating code testing
automating infrastructure
automating workflows
while continuously measuring application performance.
The way this works is by slicing the work into small chunks, taking only hours (usually) to integrate, test, monitor and deploy, versus the traditional way of writing large pieces of software over weeks and then spend other weeks (or months even) with testing.
In other words, DevOPS writes the configuration management code, detailing how the application should be built, which allows DevOPS teams to build infrastructure at scale, in different locations using different types of hardware.
They also track and document every change made to both codes: application and configuration.
Drilling even further into how DevOPS teams work, let’s just concentrate on some of the tools we use.
Tools:
As mentioned, DevOPS means a new set of tools and skills. Here are the most popular and what they do, in a few words:
Jenkins
DevOPS Engineers use Jenkins to continuously build and test.
Github
a tool used for source control, where engineers manage, track and document all changes made to both application and configuration management code.
Chef/ Puppet/SaltStack
it’s where DevOPS deploys in an automated fashion across multiple servers (hundreds/thousands) and in different locations.
New Relic
having hundreds/thousands of servers to manage can be a bit daunting, so tools like New Relic were created to ease reading and analyzing system logs, by providing engineers with a big picture of how the entire application is performing, helping them identify bottlenecks.
Briefly, adopting DevOPS will enable you to:
innovate faster
be more responsive to business needs
have more frequent software releases
adopt a discipline of application performance monitoring and optimizing in almost real time
Going the DevOPS route is simply smarter, as having identical development and production environments with the same configuration simply makes things leaner. Software delivery and time to market reduced from months and weeks to days and hours.