Recently, I outlined a few different ways that Apprenda can empower your IT organization while providing immediate value to your enterprise development team.
In part one, I covered the transformation companies are going through and how IT is often stuck at the crossroads between developers, the business, and security. The next and final part will cover the different IT-focused capabilities Apprenda brings to the table to support the SDLC.
If you take a step back and look at the most common IT workflows when supporting application deployments, you end up with the following questions:
• Where do workloads get deployed?
• What gets deployed?
• Who can deploy them?
• How do I troubleshoot?
• How do I expose additional services?
In today’s post, we will cover the first two points, where and what.
At first glance, this question might seem counterintuitive to the Platform-as-a-Service (PaaS) model in which applications should not be tied to a specific server. That is still correct. Developers should be creating highly portable applications. But there are times where IT needs to be able to specify the infrastructure under which applications can run.
Let’s walk through a scenario at one of our largest customers. This organization has public and private servers running in the same Apprenda environment but due to policy, a subset of applications that handle confidential data can only reside on the private servers. In this case, IT has set up what we call a “deployment policy” to direct the deployment of workloads based on their sensitivity level to private or public infrastructure.
Another customer of ours leverages the capability to direct certain application workloads based on server-level technologies. There are still enterprise applications that rely on specific software packages to be installed on the host machine for the application to run properly. IT might be reluctant to deploy the technology on every server due to cost or licensing restrictions.
In this case, Apprenda allows the ability for developers to still gain the efficiencies of a PaaS, even though their applications might not fully fit this model. In this case, IT tags the servers that have the software installed and if an application requires it, it will only land there.
The second step in application deployment is determining what actually can be deployed on to the infrastructure. With Apprenda, the process of application deployment is automated, and by default anyone can push applications to whatever environment they have access.
But we understand that organizations do not work this way and that IT needs a way to inspect and drive standardization, compliance, and security across all applications being deployed without slowing down the developers or the business, which in the end is what PaaS is all about.
Determining the “what” in Apprenda is achieved by using bootstrap policies. In short, bootstrap policies allow the IT team the ability to inspect every application workload while it’s being deployed before it actually starts.
Bootstrappers are a powerful capability within Apprenda. Here are few examples from current customers as to how they are using them:
• Automatically deploy APM tooling with critical application workloads. In this case, our customer is using bootstrap policies to automatically reconfigure and inject the application with their internal APM tooling. Developers are now decoupled from having to wire it in themselves, and IT is confident every application that requires it is using it in an automated fashion.
• Automatically map a file-based logging configuration to a cloud-based logging framework. Apprenda comes out of the box with a bootstrapper for log4net and log4j that injects, for every application being the deployed, an appender for Apprenda’s logging framework. The same principle was applied to develop our Apprenda-Splunk integration.
• Embed SSO at deploy time for guest applications.
• Blacklist vulnerable libraries. Most organizations already have a list of vulnerable or even forbidden libraries that developers are not allowed to use when they deploy their applications. A customer is using a bootstrapper to automatically scan every application and check against this central repository. If a forbidden library is found, the application is blocked for being deployed and the developer is notified.
As you can see, bootstrappers are a powerful way for IT to drive standards, policies, and automations for every application in an automated fashion.
Stay tuned for the final blog post in this series, which will cover how IT can control who can deploy applications and how to troubleshoot and maintain the underlying infrastructure.