Hear from a number of the Apprendans who worked hard to complete Apprenda 5.0 on what they learned, what they think is important and how they made it through our most aggressive release schedule ever. Our 5.0 release has been our biggest and most ambitious to date. We’ve learned so much from our customers, and we’re proud to know we’re building the best PaaS for the Enterprise, with the Enterprise.
Fun fact: Was once quoted in Forbes; Beer brewing aficionado. (His beer is on tap at the office!)
Ryan: What is most exciting for you–from a developer perspective–regarding Apprenda 5.0?
Eric: I feel like the most exciting features are obviously the enhancements to Java and Oracle support, but there’s so much more included within this release that I don’t want to spend all my time talking about that. For me, I think one of the coolest things we’ve added in 5.0 is this idea of bootstrap policies, which allows devs to write code that the platform will run at deploy time when your app components are being deployed. It lets you do things like modify files within your app, add new files, remove files…really, you’re granted raw access to the files that are being deployed. This enables you to build whatever custom features you’d like at deploy time.
Ryan: Can you give me an example based on direct interactions with customers that influenced the implementation of the new bootstrap policies feature?
Eric: There are two really good scenarios that come to mind. The first is something that we use internally. In all previous versions of Apprenda, we’ve used something called “token switching.” This involves replacing tokens within an app’s config files with actual values as they are at run-time. For example, you could write an app that has the app-alias token in your config file and then when you deploy it, you’d switch in the actual application alias for that app at run-time. So when your app’s running on the platform, you just re-dot that value and it’s there. Historically, it was custom code buried within the product that performed this, but we removed all this code and built a bootstrapper that does it because it’s truly the perfect tool for the job.
Another real world, real customer scenario is a bootstrap policy one of our team members has been working on for JPMorgan Chase. They have a set of .NET apps that need a particular piece of configuration injected into them when they get deployed. The way we’re solving this is by writing a bootstrap policy that executes when a particular custom property is set for an app. When an app requires an additional piece of config, our Bootstrap will run, modify their web config, inject the config that it needs, and then it deploys with these additions automatically.
Ryan: Is this to increase productivity or save time?
Eric: Sure, but maybe “simplification” would be a better word. In the first scenario I described, I think the alternative would have been to have code in other parts of the product where it wouldn’t really make much sense. Now, it enables this re-usable piece of functionality to remain in one place and apply to all apps. Rather than having to put this piece of additional configuration in specific apps that need it up-front, you can instead build all of you applications in the same way and (on Apprenda) tag one as “Hey, I need this extra thing!” and the platform just takes care of it for you.
Ryan: Outside of the bootstrap policies, what do you consider one of the most helpful features you’ve added (from a developer perspective)?
Eric: Scaling options. That’s pretty huge. We’ve always let the developer have control over how many instances of their components are actually running on the platform, but that was pretty manual. Go into a UI and click “I want one more/less,” or you could use the Apprenda REST API that was introduced in 4.5.
Now, there are many more options that you can configure for how you want your apps to scale over time. The two coolest ones are Dynamic and Scheduled. You can turn on dynamic scaling and say “when a component of my app is using more than 90% of the resources, then I need a new instance of this,” and the platform will automatically scale based on load.
Scheduled scaling is exactly what it sounds like: you can say that between the hours of 8 and 9 you need 3 instances of your component because they are the busiest hours. Between 4 and 5, you only need one instance because it’s expected to be a lot quieter. In both of these scenarios, you have much more control over how many instances of your components are running.
Ryan: How is this beneficial to an organization?
Eric: It puts control in the dev’s hands. No one knows an application better than the developer that wrote it and they’re going to know how the app should respond to load.
Ryan: Other than the sheer amount of features that have gone into this release, what was most challenging thing you worked on?
Eric: For me, working on Oracle support was the biggest challenge, because it was completely new to me. In the past, I’ve worked almost exclusively with Microsoft SQL Server. So to switch hats and learn a new database system well enough to provide support at high levels of excellence was very challenging and took some time. But obviously, it was worth it in the long run.
Ryan: Could you talk a bit about our support for Oracle?
Eric: At upload time, you pick which database system you want to use: SQL Server or Oracle (although the platform does a pretty good job inferring which one you need just by looking at the scripts that are in your application archive). If you have Oracle scripts, it will default to Oracle. And if your application is multitenant, you’d get Oracle multitenancy–plus all the same Apprenda features you’re used to (if you’ve used our platform for SQL Server).
Ryan: Is there anything else you’d like to talk about regarding this release?
Eric: There are a lot of architectural improvements that generally go under the radar, but it’s just become a lot easier to work on the product. The code is cleaner, there are better abstractions in places…we’ve got a much clearer feel of how we want the architecture to be at this point. As more new features were being added, they are all fitting into how we want the product to be and it’s nice to see it coming together. It makes work a lot easier, because it’s a lot easier to understand.
For example, take de-scaling options. Regarding the scaling option that I talked about before, we realized that our abstraction on top of app components (code dealing with the metadata for guest apps) needed some improvements. It was a bit annoying and cumbersome. We took this business feature as an opportunity to clean up that abstraction. So now, working with things at the component level for customers–like the UI at JPMorgan Chase’s banking apps–is a lot easier.
Check out the other interviews in this series!