DevOps Vs SRE

Let’s start with very crisp definitions...

What is DevOps?

DevOps is a software engineering culture and practice, that aims at unifying software development and software operation.

What is SRE?

Site reliability engineering ( SRE )  seeks to improve the reliability of currently operating software, while minimising the work involved in its upkeep through various automations. 

** 'Traditional Ops' were more focussed on how effectively ( and efficiently! ) execute the day to day tasks. 

How are they different  (Or)  Do they have any common ground ? 

Google states that SRE and DevOps are not so different from one another: “They’re not two competing methods of software development and operations, but rather close friends designed to break down organisational silos.

Both these schools highly advocates automation and collaboration - thats what in common! 

Then how are they different ?

While DevOps is all about “What” needs to be done ( e.g. Cultural change , Need of Automation, Need of Measurement, need of Sharing i.e. CAMS )  ;  SRE talks about “How” this can be done. It’s about expanding the theoretical part to an efficient workflow, with right work methods, tools and so on.

DevOps engineers are responsible for executing the 'Development Automation' or 'Developers Productivity'  vision from the very beginning of the SDLC  via Agile and CICD practices. DevOps  also preaches infrastructure as code ( IaC ) automation. 

Hence , It is expected that a DevOps engineer understands the full SDLC and also has the hands-on skills  to implement changes, or has the ability to administer it end-to-end. There are many DevOps specific tools which focusses on this segment of 'Developers productivity'. 

On the other hand, SRE's  main job is to ensure that the site (i.e. “platform/service”) is always operational,  and reliable with the right tool, process and metrics.

SRE engineers are very  focused on writing codes to automate processes and eliminate toil. Now this can only happen when you help envision or raise a very fundamental question  -  'what does your developers think should change,  if they were to do the Ops'.  

 The following analogies might be able to bring more clarity and insight!

While SRE implementation may vary from organisation to organisation, there is a DevOps Checklist portal in the internet - which you may find very useful : The DevOps Checklist

Hope this article was helpful :)

Thanks ,

-Deba

RootConf-2018

RootConf-2018

RootConf is a conference where prominent DevOps enthusiasts and SMEs collaborate once a year and share their experiences to benefit the industry as a whole. This year’s conference was held in a convention center at Bangalore on 10^th and 11^th of May.

Videos from the conference: 

Day 1: https://hasgeek.tv/rootconf/2018-day-1
Day 2: https://hasgeek.tv/rootconf/2018-day-2

Hope you enjoy some of these sessions!

Spinnaker for Continuous Delivery in AWS

We have been using Spinnaker for a little over 1 year to practice Continuous Delivery ( CD ) in AWS and also for restacking of AWS ec2's with new AMI's.

Recently I was contacted by TrustRadius - a community of professionals sharing software reviews, and best practices to write a technical review on this tool. Sharing my insights here too , hope you find it useful.

Pros and Cons:

·     Spinnaker is very strong in its ability to baking of AMI(with ROSCO) and code deployments for Linux based ec2/AMI. Below are some more points:

·     Out of the box deployment strategies.

·     Open Source and active development.

·     Multi cloud deployments ( also can integrate with kubernetes)

·     Automated triggers.

·     Manual Judgements.

·     In-house bakery service, which helps in immutable deployments.

·     Easy pipeline setups using the UI , no need to write complex CFNs for code deployments.

·     "One click resize" of the underlying ec2s.

·     Exactly "one click rollback"

·     Pipelines can be scripted (SPEL)

·     Excellent search feature to search LBs , clusters etc from the UI

·     Both high level and low level view of clusters, which has fine-grained options to control cloud infra from Spinnaker UI itself.

·     SSO and RBAC supported.

·     Wide range of deployment strategies like Blue-Green , Highlanders etc.

·     We also get a centralised view of all pipelines in single place. This helps for a large enterprise. Maven is very popular, so generating RPM from existing POM.xml is cool!

Opportunity areas for Spinnaker:

·     It does NOT support CFN based deployments

·     Windows based systems finds it difficult to onboard to Spinnaker.

·     Pipeline level access authorisation is not there.

·     Support for EBS volume encryption is probably missing.

·     Attach/detach EBS volumes during deployments is difficult.

·     No support to deploy the artifacts without re-creating the servers. Only pure immutable deployment are allowed.

·     Open-source - so good and bad!

·     Spinnaker on its own has 10 underlying micro services. Managing Spinnaker needs a focussed platform approach.

·     User authentication is easy but authorisation management is not straight forward.

Return on Investment:

·     It's open source!

·     RPM based deployments can be scripted at Maven file itself , so very easy!

·     RPM based deployments bundles all code and configs together, so awesome!

Other Software Used:

          AWS CodePipeline

Likelihood to Recommend: Very Likely!  👍