Today that clear boundary has disappeared. System engineers are shifting more and more to automation and thus very basic development, or scripting. But at the other side of the spectrum, application engineers and developers are shifting more and more to the infrastructure side. Why? Infrastructure as code. CloudFormation. Boto. Terraform. AWS CDK. In a true public cloud environment, where every single administrative action on infrastructure level is a simple API call, things are changing, and DevOps is born.

You rarely saw devs running around the office with a screwdriver and rack mounts. If they needed a server, they’d ask one to be procured. And waited a few weeks. Now application engineers can quite easily build their own infrastructure to run their applications. It’s just code, right? And they do. Oh boy they do…

However, in most cases it is undesirable to have an application engineer create infrastructure. There is the principle of segregation of duties. Furthermore, it’s very rare a skilled dev has a strong infrastructure background. So while he can probably spin up resources to support his application, the question is: is it Well Architected? And that is where a next gen MSP comes into play. Cloudar was selected by AWS to perform Well Architected Reviews. Our AWS Solution Architect Professional engineers that have followed the required extra training are allowed to perform rigid reviews of existing business critical workloads. Needless to say, each environment we build, needs to adhere to the same Well Architected Principles.

But what if a developer wants to go full serverless, and change infrastructure components rapidly? Things like Lambda’s. Can he wait for an engineer at the MSP to create those resources, throw them away, reconfigure them? Probably not. The cloud allows for speed, and you don’t want your MSP to be a potential bottleneck. Now what?

Here, the answer is again: infrastructure as code. If you demand all infrastructure to be written in code, you can allow your devs to play around in development to deploy extra infrastructure resources. And then when they are happy, and they went through dev and test, and are ready to commit to UAT, insert a code review approval step. Have the engineers that will be actually supporting the environment 24×7 review the infrastructure code. Is what will be deployed to UAT and later on to PRD still Well Architected? Does it adhere to your internal support standards? And for the mental health of the on call engineers: will it be stable and not generate alerts at 3 am in the morning?

So you see that devs will need to work with sysops, and vice versa. Certainly in a project phase. You want to work as agile as possible, but still have a reliable and secure environment. One of the strong points of Cloudar is that we have both. We have a very solid managed services business, but we also have a flourishing consultancy practice. Our people love working with your devs. We like them. Sometimes we even want to cuddle them. Everything it takes to have your workload running 24*7, but reduce your time to market by allowing devs to go crazy until stuff moves to production. Because production, is serious business.

The post A new reality: Devs creating infrastructure. And how to deal with that… appeared first on Cloudar.

All of this wouldn’t be possible without the help of our great team, so please join me in giving a big thumbs up for the entire Cloudar Team.
THANKS GUYS!!

If anyone would like to know more about the services Cloudar can provide to you as a customer, feel free to drop me an mail at bvh@cloudar.be or send me a PM.

Cheers,

Bart

The post Cloudar, a short recap… appeared first on Cloudar.