Welcome!

@DevOpsSummit Authors: Elizabeth White, Pat Romanski, Liz McMillan, Yeshim Deniz, SmartBear Blog

Related Topics: @DevOpsSummit, Linux Containers, Containers Expo Blog

@DevOpsSummit: Blog Feed Post

Doing DevOps at VictorOps | @DevOpsSummit @VictorOps #DevOps #Microservices

DevOps is agnostic about particular languages, platforms or tools; it is about internal process, communication and collaboration

Doing DevOps at VictorOps
By Jason Roth

We talk a lot about what it means to do DevOps here at VictorOps, and a lot of what we talk about comes out of real practice. In some organizations, there’s a wall between developers and ops — developers make requests of ops like they’re throwing tasks over the wall.

Here at VictorOps, that wall isn’t there. When us developers need to do something that’s traditionally in the ops domain like provisioning resources or pushing out deployments, we work closely with ops. And it works the other way too — when things change in the infrastructure that need application changes, they work closely with us. Sometimes, we will just pair on the problem together at one or the other’s desk.

3370164315_d40db1a6f3_z

Understanding how the sausage is made
Huge benefits come out of sharing responsibilities between teams. The most obvious is a shared knowledge of the ecosystem — we all want a high bus count right? Having devs know how to get around the puppet configs, and having ops know how the apps work and how they communicate, can only make the organization more resilient.

Empathy is a term that gets thrown around when talking about DevOps, and it should be. Devs and ops working together has given us all a better understanding of what’s actually going on. That added understanding and perspective really helps out when there are problems with the infrastructure or with our applications.

Personally, I better understand what to do in those situations, and if I don’t know the answer, then at least I know where to look, or who and how to ask. This goes both ways — when I’m on call, I’m on the hook for infrastructure stuff, and when ops is on call, they’re on the hook for some app stuff. This just means we’re all in it together.

Extending the DevOps Mentality

OMGDevOpsBig

There are a few recent examples of our engineering team embracing DevOps philosophies.

We recently did some work on our Cassandra cluster. The changes were infrastructure related, and drove some changes into our applications. We paired together on this to make sure the transition went smoothly and that everyone understood what was being impacted by the change.

Another situation has involved extending support for our APIs and our web client. This has involved constant iterations between frontend, backend, and ops to work through application changes and supporting infrastructure. Since everyone involved was crossing over to collaborate, the entire team was able to better understand the changes, see the bigger picture and create a new process of inclusion.

In a way, doing this kind of thing with engineers is easier because it’s different levels of the same stack. We have a shared language around the technical functions we perform so there’s already a developed vocabulary and some basic understanding. It would be interesting to explore how to do this same thing with different disciplines, involving sales, marketing and support into more of the development cycle.

Tips to Get Started

19402974878_e924a0572c_z

Getting involved and giving a shit can go a long way towards building culture, respect and empathy amongst teams. That’s step one.

Don’t just ask for something and leave. Schedule time to sit down with a with your counterpart to work through a task. Follow along and be involved. Stop them and ask questions – “how are you doing that and why?” The takeaway from this experience is a shared understanding of what  the problem, solution, and process was. It’s part education and part empowerment.

Continue to push forward. There are still some small boundaries here that exist between our mobile development and platform teams, mostly because the environments are quite different. I think those boundaries are being eroded away as we all work together to unify our product design, front-to-back, cross over for things like testing and infrastructure, include front-end and mobile devs into our on-call rotations, and surface UX issues to the backend engineers. This means that everyone gets a better sense of what’s happening with our entire platform, everyone sees how customers uses the product, and that pays off as we continue to make the service better. We’re still working on it but it feels like we’re making progress.

The technology doesn’t matter. DevOps is agnostic about particular languages, platforms, or tools; it is about internal process, communication, and collaboration. If your team can work more effectively and build a better product by sharing responsibilities, it’s a win-win for everyone involved.

I consider myself lucky to work at a startup. There’s no place to hide like in a big company and you have the ability to carve out your role as you go along. We actively fight against the “not my job” mentality by helping to fix things as they break no matter what they are. For me, the heart of the DevOps philosophy is about working towards the same goal and at VictorOps, we’re all in this together.

The post Doing DevOps at VictorOps appeared first on VictorOps.

Read the original blog entry...

More Stories By VictorOps Blog

VictorOps is making on-call suck less with the only collaborative alert management platform on the market.

With easy on-call scheduling management, a real-time incident timeline that gives you contextual relevance around your alerts and powerful reporting features that make post-mortems more effective, VictorOps helps your IT/DevOps team solve problems faster.

@DevOpsSummit Stories
DevOpsSummit New York 2018, colocated with CloudEXPO | DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City. Digital Transformation (DX) is a major focus with the introduction of DXWorldEXPO within the program. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throughout enterprises of all sizes.
For better or worse, DevOps has gone mainstream. All doubt was removed when IBM and HP threw up their respective DevOps microsites. Where are we on the hype cycle? It's hard to say for sure but there's a feeling we're heading for the "Peak of Inflated Expectations." What does this mean for the enterprise? Should they avoid DevOps? Definitely not. Should they be cautious though? Absolutely. The truth is that DevOps and the enterprise are at best strange bedfellows. The movement has its roots in the tech community's elite. Open source projects and methodologies driven by the alumni of companies like Netflix, Google and Amazon. This is a great thing for the evolution of DevOps. It can be alienating for Enterprise IT though. Learning about Netflix and their simian armies, or Facebook and their mind-melting scale is fascinating. Can you take it back to the office on Monday morning though?
For organizations that have amassed large sums of software complexity, taking a microservices approach is the first step toward DevOps and continuous improvement / development. Integrating system-level analysis with microservices makes it easier to change and add functionality to applications at any time without the increase of risk. Before you start big transformation projects or a cloud migration, make sure these changes won’t take down your entire organization.
Learn how to solve the problem of keeping files in sync between multiple Docker containers. In his session at 16th Cloud Expo, Aaron Brongersma, Senior Infrastructure Engineer at Modulus, discussed using rsync, GlusterFS, EBS and Bit Torrent Sync. He broke down the tools that are needed to help create a seamless user experience. In the end, can we have an environment where we can easily move Docker containers, servers, and volumes without impacting our applications? He shared his results so you can decide for yourself.
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examining how the Internet and the cloud has allowed for the democratization of IT, resulting in an increased demand for the cloud and the drive to develop new ways to utilize it.