<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=338168267432629&amp;ev=PageView&amp;noscript=1">
DevOps

Upgrade Your DevOps

Implementing a robust DevOps department can be intimidating since DevOps can have broad cultural as well as business implications for your day-to-day work. However, here are three key areas that are great to target at any point for your DevOps team.


Implementing a robust DevOps department can be intimidating since DevOps can have broad cultural as well as business implications for your day-to-day work. However, here are three key areas that are great to target at any point for your DevOps team.

 

 

Full Transcript Below:

Cody:

If you test early, you test often, you have smaller problems to fix down the road.

Cris:

So either never test for 20 years and then it'll be back and invoke or you need to stay on top of it.

Cody:

Sometimes it does just make business sense to get it done and get it quick and trust a dev to do it all the way through. Making it up. Is it you? Is it the client? Does that conform to their standards? No automatic test is going to tell you that.

Cris:

So DevOps, this is something that I would say is in the zeitgeist and has blown up in the last five years. I think there was a lot of buzzwords that kind of coincided with DevOps. One of them being DevOps.

Cody:

Yes.

Cris:

And then we've started to actually, I think, establish what this industry is and build it out and understand the vertical, which is great. We're going to talk about DevOps upgrades that can happen, three of those in particular.

Incorporate Testing Early

Cris:

One of those I think is incorporating testing early into your application. How does DevOps come into play? Why is this important?

Cody:

Well, for one, there's a couple words for what you just said. The early testing idea that is in the buzzword sense and the acronym sense, CICD. It's continuous integration-

Cris:

Pipeline stuff.

Cody:

... specifically the continuous integration part more than the continuous delivery, but they're often together. We've talked about this a few times in other videos, but the main part and the idea of having early testing and not only early, but often repetitive testing all the time, anytime you push anything, is that if you test early, you test often, you have smaller problems to fix down the road, instead of waiting till the end of a four sprint milestone and you end up having all this code that was never really integrated together. And then you have to go through a whole testing phase and it's an unknown problem. And Bill over in the API side, didn't talk to the dude on the front end and it's a catastrophe. And that's the idea is to integrate and test early. So you have smaller problems to deal with that are more manageable and you have a more linear project, life cycle and progression.

Cris:

And you can pivot faster.

Cody:

Yep.

Cris:

Because as we all know what is cool today, wasn't cool ... That's actually not true. What is cool today was cool about 20 years ago. The '90s are back. So basically-

Cody:

You're not wrong.

Cris:

... things pivot real quick. So either never test for 20 years and then it'll be back and in vogue or you need to stay on top of it.

Cody:

I'm going to ignore that other thing you just said. Definitely test often, test early, all that. It's good for you. Not testing, I mean, there's certain cases where not doing any types of testing in terms of actual automatic testing can make sense for early prototypes, really fast apps, stuff that is so small that you can barely classify it as a business project is probably a personal project. Those kind of things, if they're just quick and dirty, sometimes it does just make business sense to get it done and get it quick and trust a dev to do it all the way through.

Cody:

But rarely is that the case. More often than not, you need that testing. And specifically not only early testing a sense of CICD automatic testing, but even just acceptance testing, who are you making this app for? Is it you? Is it the client? Does it conform to their standards? No automatic test is going to tell you that. You need to know that early and often usually part of a road mapping process, which is really common here, what we do sure is to figure out all those goal posts before we've even started. But yeah, testing. It's super important.

DevSecOps

Cris:

Good. Another kind of, I'm not going to say buzzword, but something that I maybe didn't even necessarily hear it in this manner, so I will call it to buzzword for me. DevSecOps. Unpack this. Point number two, includes security early in the development process as I understand it to be.

Cody:

I don't understand why the tech industries can't use whole words.

Cris:

It's ...

Cody:

Development security operations. That's what it is. Basically, it is the same thing as the testing principle, except you're adding security layers. Figure out your authorization, figure out your server infrastructure, figure out all the security principles, the intrusion detection, the logging mechanisms, so that when you go live, assuming you're not just a super lightweight prototype when you actually have this thing live, it is ready. And if someone on the internet goes and tries to do anything, some bad actor you'll have not only evidence of what has happened, but also an idea of how to counter it even better the next time.

Cody:

And that sounds a little bit like paranoia to a lot of people, especially business leaders who just want to get this prototype out and not worry about the security, but I'll be honest, even on the daily here within my own firewall logs, doing my job here, basically we see 400 intrusion attempts every day. And that's not unusual. As soon as you spin up a server and that's just not our servers, that's brand new Amazon EC2 instances, as soon as the IP address is live, you start getting authorization attempts against that root account. Every single time.

Cris:

Even on a smaller scale, just go spin up an email account anywhere, don't touch it for half a day and then come back and see how many emails you have in there.

Cody:

Yeah, man.

Cris:

Don't tell anyone you made it, just spin it up.

Cody:

Yeah.

Cris:

I guarantee you, you are going to beginning offers for medical procedures from everywhere in the world and every kind of pharmaceutical product imaginable and so on and so forth. And you're like, "How does anyone know this is here?"

Cody:

Yeah. And that's a big part of this to realize too, is a lot of people when they imagine hackers, they think some hoodie wearing dude with ... the movie, the whole movie thing.

Cris:

A scrolling green text.

Cody:

Yeah. It's not really like that. The reality is most of hacking occurs from bots made by the actual hackers, of course. But usually they're groups of people. They're illicit businesses that get away with basically getting all these botnets together and try and further expand that network of bots using exploits that have existed for a long time, zero days, no one's heard about and all that kind of stuff. And that's yet another thing of the DevSecOps is keep your stuff up to date. It is so important nowadays. Back in the day, you could get away with running Windows 98 until 7 came out. Not that you should have, but you could have.

Cris:

You could have.

Cody:

And that a lot of time, it wasn't that big of a risk back then, but stuff is so connected now. It is an absolute risk. You got to keep everything up to date. You got to keep your securities up to date. You got to keep your firewall up to date. You got to do all that stuff. Otherwise, you're kind of just sitting there waiting for the wrong person to knock on the door.

Ongoing Monitoring

Cris:

Gotcha. Number three, Cody, how are you keeping an eye on this stuff? We unpacked it, obviously you're including all these things, but how often are you looking at this stuff?

Cody:

So ongoing monitoring. Yes. It is very important. Infrastructure monitoring, application performance monitoring application in the terms of the backend monitoring. There's a lot of different layers to monitoring in general, but it's all very important. When it comes to having let's say a simple application, like you have a web app and you have a backend and you have a database and you have a some sort of a KVP store and all this other stuff. It doesn't really matter to get too much in the technicals. Everything needs to be known if it's operating correctly based on the parameters that you set up, because over time, I guarantee it won't be. Especially if you actually are successful and grow user base, you're going to hit bottlenecks. You need to know when you hit them, ideally before users start complaining about them because that's unfortunately a lot of the time that's how people find out there's-

Cris:

A lot of people do their monitor and is, well, my users started leaving me one star reviews.

Cody:

Yeah. Yeah.

Cris:

And then they started linking me to the 404 pages on my site. And then they also told me that this version of the app just crashes.

Cody:

Yeah. And then you look at any engineering team and there's always this situation that occurs where the engineer's minding their own business, writing code, writing features, being good little engineers. And then all of a sudden someone from higher management shows up and they're like, "We're losing customers, pivot everything. Fix the problem." And quite frankly, it's a morale problem. It's a structure problem. And it also makes the business less efficient. You didn't plan for this execution and you really need to. So how do you do that? Monitoring. You need monitoring both on the infrastructure level, on the application performance level. What's the database throughput, how's the code stack looking, were there any stack errors, what's going on? You need monitoring.

Cris:

Well, and I think with monitoring, you make that joke of you have someone on high coming in and, "No, then this is like ..." If you have records and you have data and you've been monitoring things, it's really a good thing both for the developer to actually cover themselves where they're like, "Hey, you were aware of this information for a long time," or show the data that like, "Okay, this is just a blip. This is something very different. And again, we can fix this really quickly," rather than, "I told you to do X, Y, Z, and you didn't do it." And you're like, "No, you didn't. You weren't even aware of this." So I think it helps keep everyone honest, not to say that everyone at the top of the ladder is terrible. But you do run into scenarios, I think, where developers engineers can just kind of be exploited because they don't have the tools at their fingertips to back up some of the data sometimes.

Cody:

No. Yeah, absolutely. And I think also a lot of this, the kind of negative interactions that some developers will have with management and whatnot is often simply because often management. You're just not aware of what's going on in the technical world.

Cris:

Sure.

Cody:

You're focusing on operating a business. And then all of a sudden, when you become aware of a major problem that you thought was handled, you panic, you want this thing fixed right away because it's causing an issue in your world now. It's expanded beyond the engineering domain. And that just leads to that experience for everyone. So I guess kind of wrapping up, there's like three points here-

Cris:

Yeah, there's three point but they're very important.

Cody:

Yeah. Early testing, DevSecOps aka making sure your security's good and ongoing monitoring. All those things are incredibly important for the success almost any technical application, whether it's a mobile app, whether it's a web app, whether it's even a desktop application that has some sort of testing flow or a backend or whatever it may be.

Cris:

Because as we, I think have established, no matter whether you like it or not, the moment you start developing and building something within the space of tech, you put a target on your back. So probably not a bad idea to put a Kevlar vest on first.

Cody:

Good analogy. Yes. I do agree.

Alexandra:

Thank you for joining us for this episode of Bixly Tech Tuesday, where Chris and Cody talked all about three major areas where you can upgrade your DevOps and make sure that you're doing a fantastic job with your DevOps services. If you have any questions at all about what they talked about today, go ahead and leave them in the comments and we will get right back to you.

Alexandra:

And don't forget to check out the description box down below. We have a bunch of really helpful links for you guys, including a link to our free DevOps guide, which will really help you out, if you are in this phase of app maintenance or you're looking for DevOps services. You can also find us online at bixly.com and there's a big button right at the top that says start my roadmap. That actually gets you a free 60-minute call with Chris to talk about your next app idea until next time, this has been an episode of Bixly Tech Tuesday.

 

Similar posts

Get notified about the latest in Tech

Be the first to know about new tech from the experts at Bixly!