At Cegeka, we’ve been building applications for our clients for many years. We know from experience that application development is always tightly enmeshed with the underlying infrastructure. And we’ve been seeing a shift in this infrastructure – more and more, it’s moving away from the Cegeka data centres into the public cloud, with Microsoft Azure as the key player. Some clients are going all the way for public Cloud; sometimes we’re seeing it as part of a hybrid set-up. We realised that the same challenges were emerging over and over again, and so we started to think about how we could take a structured approach to tackling these issues.
Specifically, every application developer faces three key infrastructure challenges: observability, security, and self-service.
It’s common to find that the teams that hold responsibility for infrastructure and app development each have their own monitoring tools. As a result, the insights that flow back to the developers are piecemeal and incomplete. Without a complete ‘big picture’ view, it can be a challenge to identify the root causes of problems related to availability, performance, compliance, security, etc.
What you need is seamless end-to-end observability. In other words, the ability to understand the internal state of your system based on its outputs. Otherwise, it’s impossible to guarantee a minute-by-minute overview of the system as a whole. And that means you need a tooling landscape developed not on the basis of the technology, but oriented to end user expectations.
The traditional approach of first developing an application and then submitting it to security testing before it goes into production is no longer adequate. What happens is that once the security experts have tested an application, it always needs significant work to resolve vulnerabilities – thus delaying the production rollout.
A better approach is Shift Left Security. Shifting security checks left means integrating them into the development process from the very beginning, with continuous testing of the code, with e.g. runtime scanning. At the point when you need to decide whether the application is ready for production rollout, the security checks have already happened, so there won’t be a need for major revisions that would delay rollout. What’s more, this approach can be used beyond the application itself. If you define your infrastructure with code (‘infrastructure as code’), you can also automatically and continuously scan this code to confirm compliance with a specified security baseline or security best practices.
Interactions between app developers and infrastructure managers can often be a source of congestion. The application developers identify their needs and communicate them to the infrastructure team, who will then need quite some time to come up with a solution. This holds up work for the app developers as well as tying up the infrastructure team’s resources.
An alternative approach is for the infrastructure developers to build a library of standard platform components that can be offered through a self-service portal or code that is embedded in the Kubernetes deployment. When the app developers need certain platform components, they can simply select them from a list.
The self-service portal allows app developers to integrate and deploy a selection of infrastructure components without needing to understand their inner workings. This infrastructure layer can be run in either a private or a public cloud. At Cegeka, as well as operating our own private data centres, we have the expertise to support developers via the Microsoft Azure public cloud. The developer has access to transparent landing zones with containers based on Azure Kubernetes Services (AKS).
Cegeka’s approach to these challenges
A number of clients facing the kinds of challenges described above have come to us for help. In fact, our own developer teams had already noticed a similar problem here at Cegeka. At the start of each project, they would identify the same set of basis components needed and so they were doing the same thing every time: developing a platform before they could start on the project.
We realised that a DevSecOps infrastructure platform would save a great deal of time for both us and our clients. What’s more, by using standard components that follow best practices, we can ensure that the ever-increasing security and compliance requirements are met. We integrated feedback from clients and developers into our own managed platform that gives developers the infrastructure they need, so that they no longer find themselves building a new platform from scratch at the beginning of every project.
To provide enhanced monitoring, we took the step of extending our already mature infrastructure monitoring tools into what has become a complete platform and application monitoring system. This delivers an end-to-end overview from infrastructure to application. In addition, we have an extensive set of components that make it possible to set up observability insights.
To guarantee security, we opted for an open architecture, which allows us to easily integrate new tools for security and compliance testing. Finally, we’ve combined all these solutions into a managed service with a self-service portal that application developers can use to select platform components. The portal makes life easier for both our own developers and our clients, who can now get projects off the ground much more quickly.
Managed DevSecOps platform
In a recent interview, Gaetan Willems, Hybrid Cloud Director at Cegeka, explained the objective of our managed platform from his infrastructure perspective:
‘The platform includes all the non-functional elements, plus DevSecOps tooling. Developers no longer have to reinvent the wheel every time they start a project and can put all their energy into the primary task. It’s a great saving in time and resources for us and for our clients. The framework also gives you a guarantee that the ecosystem will be standardised, secure and high performance, whether you opt for a private or public implementation model.’
Toon Martens, our Application Modernisation Director, sees things very similarly from the application perspective:
“Your best option is to invest in a cloud-native application platform which has all the non-functional elements as standard. Your developers can then put their energy into building the actual functionality, without having to start from zero every time. By shifting all the non-functional elements to an automated platform, you don’t just boost efficiency – you also establish a secure, stable foundation.”
Are you tackling issues relating to infrastructure, observability, security and self-service as part of your app development process? Get in touch with us to see how our managed DevSecOps platform could help make life easier for your application developers.