Getting smart with DevOps in Boston and how to overcome the tidal wave of config data

Ben Riley, Technical Director

So, I met some super interesting people all with different challenges at DevOpsDays Boston last week. I’m not jealous of their challenges either. It sounds tough. I heard from lots of incident management people who are dealing with downtime outages and that type of thing. So I found it really useful for just trying to get a handle on the operations side of things. It was a real mix of people and a really good couple of days.

It’s a really fascinating space right now for DevOps, because everyone wants to automate everything. But It’s deciding what’s the right parts to automate. It’s a piece of the puzzle that lots of people struggle with. So it’s been really interesting to hear that and it’s a very exciting space for us at the moment.

Being able to correlate config data across applications and infrastructure is good. And talking to the network guys, they need to configure their network devices based on things that are happening in their applications and based on the type of containers they have in their application. That will determine the way their network needs to be configured.

Often times things get out of sync because there was an application change that they weren’t aware of. So having that config data in one data model allows them to know when something’s out of sync and catch it earlier on in the cycle.

I see config data as the next big thing as people start to get a handle on other parts of their DevOps tool chains and the roles within their CI/CD. Config data just keeps growing and it lives outside of these processes and these areas. Some people had a bit of a handle on it, and some don’t even see if as a real problem yet. That’s not to tar everyone with the same brush but maybe their business isn’t mature enough to spot those different things right now.

People just see a tidal wave of data that can kind make or break you in many regards when it comes to releases. So how you manage and tackle that complexity is crucial to your success and to the relationships between these dependencies. Sometimes you just don’t know what’s going to happen to the app when you flick the switch. And you try your best to react to it but you’re really just chasing your tail.

So for me, over the last few days in Boston, it’s been about prevention and putting a set of good processes in place. Let’s fix this beforehand. Before it really impacts you and before it goes into your end user experience. People I’ve spoken to over the last few days absolutely agree with that and don’t want to be in the dark about it.

I’ve worked with data management solutions in the past. And it’s refreshing to take holistic view. Calling someone’s baby ugly isn’t going to get you anywhere.

So we focus on being a central point for config data that’s not intrusive and not there to annoy people. It’s from here that there are a whole host of things we can do to assist. Sweagle is very malleable and flexible to solve very specific SLAs or challenges that customers have.

We fix problems with people and that’s kind of good.

Posted in

Further reading on DevOps

Once you’ve read this Blogs, you might want to look at these resources from the DevOps archives.

Leave a Comment

Your email address will not be published. Required fields are marked *