Lunch & Learn Series: Why You Need DevOps

The Speaker

Mike Poirier, DevOps Engineer at Bambora

Mike Poirier was our speaker for our January 9th Lunch & Learn, and he discussed the hot topic of DevOps. Our team at FreshWorks is always looking for ways to improve our development processes and were happy to dive deeper into this topic. Mike has gained experience with DevOps through his various roles, and is currently a DevOps Engineer at Bambora. He shared his views on the topic and – rather than giving us an update on what’s hot in the DevOps space – he explained:

• what DevOps really is,

• why you need it, and

• how you can do it better.

Like all good experts, he also encouraged us to come to our own conclusions, and understand that there is a world of more information about the topic. This article aims to summarize some of our takeaways and we hope you may find value in the lessons for your organization as well.

What is DevOps?

DevOps Is:

The Ops for Devs!

The main goal of an operations team is to ensure everything is stable, sustainable, and efficient. This is true for all operations teams. Developers build the products, and their work requires planning and organization, along with an operations team, to ensure things go smoothly. DevOps is a methodology to achieve stable, sustainable, and efficient development through best practices.

The DevOps Methodology aims to:

• Increase frequency of deployments

• Lower failure rate of releases

• Reduce down time

• Shorten time between bug report and fix

• Faster MTTR (Mean Time to Recovery)

Increasing the frequency of deployments has a direct effect on failure relates of releases. Mike tells us that people have put a lot of research into this, and explains that “the more releases you do, the less bugs you have”. Although this seems counterintuitive, the smaller changes you make, the more you can predict how that will affect your system as a whole. This ends up reducing downtime, and allows bugs to get reported and fixed faster.

By using DevOps methodologies, developers can release code faster, and more efficiently, improving developer operations overall!

DevOps isn’t:

• A cult (despite what critics may say)

• A technology, nor a combination of technologies

• A team you hire

• Continuous delivery (although this is an extremely important element)

• The answer to everything

Because DevOps is a methodology, it couldn’t be done without the right culture and practices to facilitate it.

Culture and DevOps

Like Agile, if the organization doesn’t adopt the idea and processes as a whole, then it won’t work. A culture is needed to facilitate effective DevOps – and these parts are what is most important.

Work in Cross-Functional Teams

Having a team responsible for the entire lifecycle of the application is extremely valuable, and when the team contains members of every discipline and department, everyone in the team can really take ownership of the application. Everyone is knowledgeable about the project and its elements – but this does not mean that Designers write code and Devs design. It just means that they completely understand the project objectives and can if required (assuming they knew how to use the tools). This makes communication and collaboration more efficient, and makes deployments easier.

At FreshWorks, we use cross-functional teams on every project. Each team member supports the project until the final release, and following this agile structure has helped us with our communication and collaboration over all.

Get Ops & QA Involved in Planning

Planning shouldn’t be solely about development, because there is more to the application than just building it. QA and Development take time, and should be considered in estimation. Also make sure to consider infrastructure and deployment planning as early as possible. Doing this will make estimates more accurate, and you will be that much more prepared for releases.

Make Data-Driven Decisions

Development decisions that are supported by data are much more successful and efficient than ones made from gut-feel. Decisions that impact the architecture of the code are best made from the data itself.

Focus groups were used as part of our recent project with Harbour Air.

All decisions about an application can be made in a strategic and educated way. This is evident in some of our recent work with Harbour Air. Before we even started working on writing code or creating designs, we conducted focus groups, took a look at heatmaps, and other analytics to make an educated decision about the development and design of the web and mobile apps. This was a very rewarding process, and the final products proved to be more successful because of it.

Shifting Left

Take as many processes as possible, and put it in the timeline as early as you can. With agile and scrum, everything is done in a Just In Time approach, but doing this will generate the feedback earlier in the process. With earlier feedback the team can involve as many resources (design, ba, qa, etc) as soon as possible and avoid going down paths that waste a bunch of time and effort.

We have recently been working harder to do this in our teams here at FreshWorks, because we have found that at the very beginning discovery phase of a project, developers and designers offer invaluable insight that identifies problems earlier. This improves the quality of solutions implemented down the road and speeds up delivery time

Tools and Practices in DevOps

There are several tools and practices that Mike recommends using to get the hang of the “DevOps way” of doing things.

Continuous Integration/Delivery/Deployment

DevOps kind of originated out of Continuous Delivery, in that DevOps encourages frequent deployments to minimize effort and maximize efficiency. For those interested in CI/CD, Mike recommended a book written by Jez Humble & David Farley, called Continuous Delivery. Many consider Jez to be the messiah of DevOps – he actually wrote the handbook for it. Mike highly recommends Continuous Delivery if you are interested in learning more about the topic.

FreshWorks developers have implemented CI/CD in several projects so far. One of our most recent experiences with CI/CD has been implementing a new pipeline for our client, BC Hydro. From our experience, we definitely agree that the development cycle on a project with CI/CD support is much faster and less error-prone, and hope to take it into more projects as we work on our DevOps at FreshWorks.

Automated Testing

The benefits of automated testing are:

• Consistency – machines will do the exact same thing, every time.

• Less BS – you can be sure no typos are going out.

• More time for cool stuff – work on other problems, and use your time better.

However, automation really only works if it saves time! Don’t automate something if it is more work than it’s worth. Most value will come from automating repeatable tasks that are prone to error.

Immutable Build Artifacts

Typically in 2019, this refers to docker containers. By bundling the code with its environment, there are fewer variables when moving into different environments. Configuration items that are different between environments are typically handled with environment variables or external configuration files, not by rebuilding with tags or parameters.

Configuration Management & Infrastructure as Code

There are two steps to setting up an environment.

1. Build the infrastructure (all the servers, services, etc.)

2. Configure it (install all the things and make sure they are set up and working correctly; this is called configuration management)

Both can be captured as code, to the point where you can automate an entire infrastructure, configuration and deployment from files that you check into your repository.

1. Configuration management is the way to define how you want a system to look (what programs you want to install, what networking you want, and anything else you can configure). This is the typical target for scripting because it is laborious and risky to do manually (following a long installation document, for example).

2. Infrastructure setup has always been a manual process, but with the cloud computing revolution, we can now script this as well. We can define in a script – using cloud-specific language – the holistic view on how you want everything to look. By running the script we can create an entire infrastructure from scratch in a repeatable way. If we make changes we can blow away the old infrastructure and run the new script to create it again with the change we want.

Infrastructure as code is better because:

• Infrastructure deployments are now repeatable and consistent

• Infrastructure and config changes can now be reviewed and merged

• These changes can be tested before going live

• Dry runs are now possible

• Environmental differences are known and minimized; code is consistent between them

• Devs can see in code how prod is set up and the implemented changes

Monitoring

It is important to monitor the basics (CPU, Disk, Memory), and anything that you think is important. What consists of useful information will vary wildly based on your company or team. The worst that could happen: you have too much data, and that problem is a lot better than having too little data.

Ask yourself “what info would I want to know if there were…”

• • • Timeouts

    • Complete outages

    • Large numbers of errors

Overall, monitoring should help you understand what is happening to your stack. Collect any data you think is valuable.

Alerting

Alerts notify you when something is wrong, and should always be actionable and relevant. Low priority things can go to Slack, or whatever chat is used in your team, and whatever you do, don’t send alerts to email inboxes! Don’t forget to create Service Level Agreements (SLAs).

Agile + Scrum

At FreshWorks, we follow agile methodology, and use a scrum framework to manage our teams. A question was asked during this Lunch & Learn: What are the differences between Agile, Scrum, and DevOps? Let’s look at some of the similarities and comparisons.

First, scrum is a form of agile.

• Agile – Methodology to help improve the communication between stakeholders and development teams to ensure a quicker feedback cycle.

• Scrum – A framework in which teams operate, involving short development cycles, providing complete value at the end of each cycle.

DevOps, on the other hand, is something that works in tandem with Agile. Both are methodologies, with similar yet different goals:

• Agile – Methodology to reduce the time for stakeholders information to get to the developers.

• DevOps – Methodology to reduce the time for a product to get to the stakeholders.

Our Takeaway

Although FreshWorks seems to have checked some of the DevOps boxes, we have the humility to recognize there is room for improvement; we will be working hard to build DevOps into our culture and practices. We strive for excellence in every aspect of our work, and Mike’s presentation set us in the right direction for continuous and incremental improvement in the coming months.

There is a wide range of opinions on DevOps, its meaning, and how it is done. We would encourage any team to ask questions, share your views, and come to your own conclusions.

Let us know what you thought about this take on DevOps in the comments!