Creating a self-service platform, helping developers to deliver applications faster to the cloud.
EuProGigant: Policy as Code in Data and Service Ecosystems
8 min read - 12. Juli 2024
Using AlloyDB to power the next-generation e-commerce solution.
7 min read - 04. Juli 2024
Technologies used
Our customer has built a self-service platform on top of Google Cloud, allowing its developers to create, deploy and monitor applications on Google Cloud, thereby significantly shortening existing application’s release cycles and minimizing new application’s time to market.
8 min read - 12. Juli 2024
Seeing the benefits of the cloud, companies decide to undergo a cloud transformation, only to quickly realize that it’s harder for the developers, as these suddenly find themselves in the domain of cloud computing. Now they are faced with questions as “how to securely build and deploy applications on the cloud?”, “how do databases hosted in the cloud differ from the ones the company has on-premises?” and “how is the health of the application monitored”. The list goes on. Developers start learning about the cloud, but it comes at a cost: the application’s deadlines get postponed, and business is not getting its promised features. This gets worse, if multiple teams are moving to the cloud, but due to the company’s structure they are not in touch with each other. Both teams face almost the exact same challenges and solve these on their own, without sharing knowledge or exchanging experiences.
Results
Nothing shows the success of the Application Platform better, as the fact that it was soon rolled out for the entire organization. Now developers are neither overwhelmed by the complexity of the cloud, nor are they dependent on any “operations team” to create, deploy and manage cloud applications, which resulted in significantly shorter release cycles for existing applications and faster time to market for new applications.
Solution
Developers not only need to create, but also remain in charge, while running their applications to minimize reaction time in case of incidents.
The customer's solution to the problem was to create a selfservice platform named “Application Platform”, where developers heavily rely on pre-configured templates and well-maintained “example applications”. These are continuously kept up to date by the Application Platform team, and thereby removes the burden from developers to interact with the cloud on a deeper level.
In the early days of the platform the first major improvement was the introduction of continuous integration and continuous development (CI/CD) pipeline templates. Integrating these templates meant that their existing applications were now scanned for security vulnerabilities, built, thoroughly tested (unit-, integration- and load-testing), and securely deployed to the cloud. Next came the improvement on network integration, so that developers had nothing to do, and their applications were able to communicate with each other and were accessible from the outside as well.
A well designed CI/CD pipeline not only ensures that applications are built and tested, but also that security vulnerabilities are caught at an early stage of development. Rolling such templates out for the entire organization means that every team benefits from it. Are you aware of all libraries and tools your developers integrate into their applications?
As the platform gained attention within the organization, the need for Postgres databases arose. Using Google’s managed database solution – CloudSQL – the problem was quickly tackled. The next question was how applications and developers get the necessary credentials to connect to these databases. To solve this question, HashiCorp’s Vault was integrated into the platform, which is a secret management tool specifically designed to control access to sensitive credentials in a low-trust environments. Developers didn’t have to bother with secret management anymore, a topic which if otherwise taken lightly may cause serious damage to the company.
On a scale from “never” to “newly generated for each usage”, how often do your developers rotate database credentials and secrets? Does the term “ephemeral secrets” mean anything to them?
The final milestone was to allow developers to monitor the health of their applications so that they can react quickly in case of incidents. This was critical as once applications ran in production, these must meet certain quality criteria (Service Level Agreements aka. SLAs). Soon the Application Platform started offering a fullblown monitoring system allowing developers to monitor their applications real time. To take it a step further generic alerts were introduced, so that developers were automatically notified of the most incident types.
Challenge
Related services
Weitere Referenzen
-
Developers coming from a traditional software-engineering background, don’t need to be trained for the cloud, instead they can start developing applications and thereby create business value from day one.
-
Using pre-configured templates, developers can create a new application in less than five minutes and deploy these to the cloud.
-
Newly created applications are automatically connected to customer’s monitoring and alerting system, allowing developers to react and fix issues quickly.
-
At each deployment, applications undergo various security checks, making sure that these conform to the highest security standards and are not vulnerable to attacks.
-
Running on the cloud allows the customer to scale applications on demand, and therefore only use as much compute resource, as is necessary at any given time. This way they can cope with changing load over time, while keeping compute costs at minimum.
Key results
What’s the most effective way of onboarding existing developers and helping them to start developing applications that run on the cloud, without getting tangled in its complexity?
A solution could have been creating a “cloud operations team”, whose responsibility was then to configure and run applications created by developers. The CloudOps team however could have quickly become a bottleneck, as the number of applications steadily grows. Moreover, if there was a bug in the application code itself, and the CloudOps team was alerted to this issue, there was little they could do to fix it, as the application itself was not written by them. In conclusion developers not only need to create, but also remain in charge, while running their applications, so that incidents can be fixed in the shortest time possible.