How Stacksmith helps to package, optimize and maintain your application in a consistent way

Authored by Jota Martos, Engineer 

Building an application from scratch requires a huge effort from the developers of the application. Apart from defining the pre-requisites (language, runtime to use...), it is the time you spend in writing the code and building, packaging and deploying the solution. If your application will support different platforms, you will also need to spend time building a system that meets these additional needs, and that requires knowledge and time to integrate into your system. 

On the other hand, there are cases in which you will use a commercial or Open Source application that does not require code changes but does require changes in the way it’s deployed and configured. In these cases, automating the process to package and deploy the application so it meets your needs can deliver key benefits to your business. 

These benefits include time saving from the reduced effort it takes to incorporate your changes (and not just once, but every time the application package needs updating), and it improves the consistency and quality of what you produce by minimizing human intervention and the possibility of human errors. That’s why you need to put a system in place to automatically package and deploy it every time you integrate a new change in your application.

Many organizations that are evaluating what this means look to Continuous Integration and Continuous Deployment tools (CI/CD) to solve the problem. These tools are often either overly prescriptive - they only work with particular application runtimes or cloud targets, for example - or overly flexible, requiring substantial customization for them to work in your specific environment. 

While these tools are right for many situations, they won’t be right for all. For those situations that don’t require a fully automated CI/CD software delivery process, there is still an opportunity to gain many of the benefits they can deliver without having to implement a full CI/CD strategy. By packaging the application code and configuration as deploy-ready artifacts, images, and associated deployment templates, and delivering that application in an automated, repeatable way, you can obtain the transformational effect and long-term maintenance benefits typically only achieved with CI/CD tools. Here is how it can be done.

The importance of automating the application packaging and delivery process

The process of packaging and deploying your application is time-consuming so increasing productivity when performing these tasks is always a good idea. Automating these tasks allows teams to focus more on the development of applications and less on the system details of delivering it to computing environments.

Some of the benefits are: 

• Teams can test the changes easily and frequently, which leads to a better performance. Because the process is automated, it is easy to validate even a small change in the application by packaging and testing your solution with the changes. 
• Automating the delivery provides a repeatable and reliable way to promote application changes - not only for the production environment, but also for the development, test or any other environment that the team uses when deploying an application.

Bitnami Stacksmith is a tool that automates and optimizes the packaging of your applications for deployment to cloud and container platforms. It also includes many more features such as multi-platform support, security checks or methods to upgrade or downgrade and maintain your application.

Stacksmith only needs the files of your already-built application (for example a .tar.gz file or your Node.js application) and it will package it for the cloud or container platform you select. Stacksmith provides a consistent, reproducible, and automated way to package your applications. 

In addition, Stacksmith can be integrated with your CI/CD pipeline. After the application itself has been built and tested, the build output can be passed to your CD tool for the deployment of the updated version of the application to the staging environment. This Bitnami blog post has some examples on how to integrate Stacksmith with other services.

Not only packaging automation: Other benefits of Stacksmith

Target different platforms in a single process

Stacksmith lets you package your applications for multiple platforms. This means you can package your software for AWS and Azure with just a few clicks. When you package for AWS, Stacksmith creates an AWS CloudFormation template for you, along with an Amazon Machine Image (AMI) that contains all the necessary dependencies for your application. When packaging for Azure, Stacksmith creates an Azure Resource Manager template for you and a managed virtual machine image. If your focus is Kubernetes / containers, Stacksmith also lets you create container images and Helm Chart that can be deployed to the container services of those platforms.  

Stacksmith also allows you to create different applications depending on the target and the files and scripts you want to package. For example, you can configure the AWS solution to use the “Java Tomcat Application with DB (MySQL)” architecture, yet configure Stacksmith to use PostgreSQL when packaging for other platforms.



Security

One of the goals of Stacksmith is to maintain your application by keeping it secure and up-to-date. To accomplish this, Stacksmith documents the components that were installed when packaging your application, then continuously checks for updates and known security vulnerabilities for any of these components. All this information is shown in the “System Packages” section of the build you select.



Here you will also find alerts about security issues affecting these components and information on how to repackage the application.

This ensures a smooth process for upgrading your application, making it easy to repackage a fixed version of the application and update existing deployments to fix any security issues.

Upgrades, downgrades, and maintenance

Stacksmith allows you to update your application at any time by uploading new files, and it also supports downgrades for when you wish to return an application to a previous state. To illustrate this, I am going to update the application by providing new files and packaging a new version of it:  

1. From the “Applications” dashboard of your project, select the application you want to update. 
2. Click “Edit configuration”.
3. Provide the new files of the application and add a version number for the new build. 

This feature is extremely useful for those users who don’t have any automation in place because it gives them the opportunity to easily package any other version of the application in just a few clicks. Stacksmith will save the information about all the packages it has been generating, all the previous versions, and the new ones that will be accessible through its dashboard. 

When editing the configuration, you can also perform other tasks, such as changing the template you wish to use (in case you want to change the database the application uses, for example) or the target platforms (you can add or remove support for AWS or Kubernetes in the different versions you build).

Once Stacksmith has built an updated version of your application, it can be used  to update the existing out-of-date one.

Stacksmith's built-in stack templates are designed to make it easy to update the application in mind. In most cases, the upgrade or downgrade can be done with zero downtime for your application. This is because Stacksmith lets you use the cloud-native load balancing and other mechanisms available on each platform. In the case of AWS, Stacksmith leverages Elastic Load Balancers and Auto-Scaling Groups to achieve this goal.

In order to update an existing deployment, you only need to copy the CloudFormation template HTTPS URL, go to AWS CloudFormation console, choose the ‘Update Stack’ option, and provide the new template URL.

Automation is the key

This article explains how Bitnami Stacksmith is a really useful tool to package your application, regardless of the source of your application files or how automated your current process to package your application is. It will provide a consistent and reproducible way to package your applications, and  leads to better quality and reliability of your application.

With Stacksmith, your application can be packaged for multiple platforms in just a few clicks. Once you provide your application files, the system will package the application and make it accessible in the platforms you select. Stacksmith automates ongoing maintenance, keeping your applications secure and up-to-date by applying the latest security patches as well as the latest configuration and other internal updates you integrated into the application. 

Try Stacksmith Public for free now for your Open Source projects, or enroll into one of the other Stacksmith plans to experience all the benefits of Stacksmith.

Try Stacksmith Public

Have questions about how Stacksmith can fit with the CI/CD tools you currently use? Contact us at enterprise@bitnami.com.

The Rise of Application-Centric DevOps - How Treating the Application as the Asset Increases Trust and Security in the DevOps Process

Written by Matt Small, Head of Solution Architecture

Application-centric DevOps

DevOps is about running applications not infrastructure.  For all we talk about DevOps, closing the gap between code running in dev and code running in production, it’s odd that Ops is still forced to take an infrastructure-centric view of the world, while Dev continues to take an application-centric one.   Shouldn’t we care most about the application itself?  After all, it’s the sum total of all the parts of an application--the code, the dependencies, the infrastructure, the deployment policies, the integrations--that is valuable to the business.

The solution to this--packaging everything required to install and run an application on a target--was solved a long time ago for desktop software with installers.  Since then, the steady waves of disruption to both engineering and operations practices have led to the decentralization of applications and infrastructure alike and proliferate ways to address and automate all of it.  Interestingly though, the idea that we should be taking all those increasingly distributed and disparate components and version controlling them as a package has not been compellingly reincorporated.

How did we get here?

In Ops, IaaS forced us to consider that infrastructure existing at any given moment is not, in fact, a given.  We planned for failure.  We imaged things and launched infrastructure from those images.  When that proved to be too inflexible for the agility of cloud, we adopted launch-time configuration management and orchestration as a best practice.  Let’s start with a golden image that’s versionable.  Let’s layer in scripts to configure the machines, also versionable.  Let’s tie it all together with orchestration so we get a fully functional deployment that can run the application that Dev provided us.

PaaS promised to simplify this tier by tier.  We incorporated that into our orchestration and stitched these services together with IaaS and other API-driven resources, again in the aim of running the code that Dev provided us.

Meanwhile, Dev ran down the path with ubiquitous source control, continuous integration and continuous code deployment processes.  We ensured they too could iterate quickly, partying on issues, testing and releasing early and often, breaking and fixing things with haste.

Then Dev hopped to the other side of the philosophical lemniscate with containers.  Suddenly Dev is the one imaging things and could hand something to Ops to run in staging or production that they had just been running locally.  Immutable image building was back in style and each tier could be more easily versioned once again.

Containerless...ahem...serverless is the next wave washing over us.  The code just runs in the box[es].  Pay no attention to the man behind the curtain!  Now we can incorporate all the best microservices from the most appropriate providers, and the middleware that glues them together with the datastores they need.

Ops trudged along and while they were happy to argue less frequently with Dev about what's going into the box, they were simultaneously dealing with exploding application architecture complexity.   We continue to do our best to stitch things together.  Though increasingly we’re dealing with broadly heterogeneous environments leveraging containers, instances, APIs, managed and unmanaged services (RIP CMDB).  An application can be made up of one, some or all of these.

What’s the alternative? 

Reconverging on the center of the DevOps leminscate, and bringing back the application-centric view of packaging and versioning everything as a unit. Take the code itself, its build dependencies and boot logic, the orchestration required to configure and deploy it and the governance policies it needs to follow to successfully run in a target platform, and make that an immutable, versionable object.  You now have the packaged concatenation of DevOps.  In this approach, the leminscate connects, it doesn’t overlap and chase its tail.  It creates a trusted handshake between development, security and operations whereby all of their requirements, opinions and policies are converged.

Dev maintains control over the application, its version, the explicit dependencies they care about and the application’s boot logic within their tool chain.  Ops and security lock things down, orchestrate the requisite cloud services, and integrate deployment and operational dependencies and policies using their preferred tool chain.  The creation of a versionable, immutable, deploy-ready Application Package during the asset build and assembly process ensures that everyone’s requirements and policies are factored in at a point in time.   Whenever we have a question about what is running and how, everyone knows exactly where to look--the Application Package.

When fully automated, the upstream CI tool converges the code and places a trusted code asset in an artifact repository and development manages their dependencies and application configuration requirements in source control.  Continuous Application Packaging consolidates the code and other artifacts with the policies and automation required to run it whenever there is a change and places a trusted Application Package back into the artifact repository.  Changes can be triggered by new code updates or external events such as a CVE that affects an included system package.  Downstream, a CD tool or orchestrator would pick up that Application Package and deploy it.  The deployment automatically wires up everything that was packaged in as a requirement, such as operational monitoring and logging tooling.

By acknowledging and packaging the hand-off of applications from Dev to Ops, we are  establishing new trust in the Enterprise between these teams, that their requirements, policies and opinions will be factored in.  We are allowing them to work with their preferred tooling and specialize in their domain knowledge.  We’re advancing our understanding of immutability by applying those principles to the entire application.  And we’re preparing ourselves for the next wave of disruption as applications continue to break apart into microservices, functions, and whatever the next building blocks will be called.

Packaging applications is as easy as v1, v2, v3 with Bitnami Stacksmith.  Stacksmith does the packaging, logs everything that goes into them and continuously monitors components and repackages applications with security and system package updates.  It provides a self-service and/or API-driven way for Dev and Ops to finally close the gap.

The hunt for modern marketing automation

Is “marketing automation” a nicer term than “email marketing?” I’m not sure. But one thing I am sure of is that every modern startup is doing it, and if you’re not, you’re missing out on a tremendous opportunity to help customers learn more about your products and services.
       
The problem for startups like our own is that most marketing automation systems — Marketo, Hubspot, Eloqua, Pardot, etc., — are expensive, feel dated, and have complicated UIs. Cost is relative, but most enterprise startups have only a few hundred to a few thousand users for for them, perhaps, the $2000+ per month on marketing automation is justifiable. But at Bitnami, where our user base is many times that size, the costs of traditional marketing automation vendors go up astronomically. The established marketing automation vendors have been in business for a while, some for as long as twelve years, and their platforms are showing it. Many are over-featured and built on a previous generation of technology. With all those features comes unnecessary complication — many screens, many fields, many rules and hidden costs.

Perhaps the most frustrating part about shopping for marketing automation system is the old-school way of evaluating the choices. In short, you can’t really evaluate them. These vendors follow a traditional enterprise software model that sells you on promises — “ease of use,” “flexibility,” “great support” — that may or may not be true. Even those few that do allow for evals don't really allow you to try everything in real-world production situations.

Fortunately, there are a slew of new startups who are disrupting the market. Two in particular caught our eye: Customer.io and Vero. Spoiler alert: we selected Vero because their UI was a bit better for the marketing side of the house their pricing model better fit our business, but both were really a breath of fresh air. It's not completely fair to compare Customer.io and Vero with other marketing automation systems — and in fact neither company uses the term "marketing automation" on their website — but for our needs Customer.io and Vero had the 80% of the features/functions of a marketing automation system at a quarter of the cost.

Criteria

Some background. Bitnami was founded in 2011 and went through YC in winter 2013. With over a million apps deployed per month and tens of thousands of new users registering every month, we needed a better way to communicate with customers, personalize emails based on triggered events, A/B test our messaging, and measure results. Specifically, our goal is to make our customers successful with the applications they're using. For example, we want to make sure people who deploy WordPress or Magento have the information they need to get up and running, personalize and customize the application, and be productive quickly. We required a system that was flexible and powerful enough to support all the many use cases.

After looking at the traditional vendors, we turned our attention to Vero and Customer.io. We liked many of the things we saw in each platform:

• They’re both startups who understand and appreciate the needs of startups and agile organizations
• They focus primarily on email (which we would argue is 80% or more of the value of a marketing automation tool)
• The products are getting updated and improved weekly, continuously increasing the amount of value we get
• They allow for deep integration and triggering custom events through a modern REST API
• Slick UIs and are built with modern standards 
• Fast, reliable support for cases when we run into issues or want to be sure how the tool works
• Transparent, straightforward pricing — you can try before you buy

The level of customization and personalization is important for us because we offer customers nearly 100 applications and developer stacks to choose from in multiple formats (native installers, VMs, and several cloud options like AWS and Azure). We wanted to be able to trigger and personalize emails based on actions users take — or don’t take. Multiply that by running A/B tests on every campaign and newsletter, and it can become a mess quickly. Lastly, we wanted something that our marketing folks could use. Every marketing automation vendor will say they can do all the stuff mentioned above, but it’s harder than it looks.

The first problem we came across with multiple vendors were the APIs that would allow us to export data to the marketing automation tool. Some lacked an API. In the cases where an API was available, they often were incomplete, only allowing access to part of the functionality, or were based on SOAP and convoluted to use.

Refreshingly, both Vero and Customer.io featured a RESTful API and ready-to-use libraries for many languages, which allowed us to get sending information and events to work from scratch in hours.
Another concern we had is with proper handling of users who change their email addresses. People often sign in using their private addresses to try our offerings, but then want to use this account for business reasons and switch emails. For some of the solutions we have evaluated, the primary identifier was the email address which made this use case very hard to handle properly. For Vero and Customer.io this worked fine and we would never run into any issues.

In some of the traditional automation tools we evaluated, small workarounds were required on our side to make things work, and even then, were less than optimal. We asked the companies if the updates could be made on their side, but their engineering roadmap wouldn't allow for it, and we didn't want to pay for professional services for features we felt should already be included in the product. However, Vero and Customer.io were much more responsive and appreciated the feedback. We have also found their support to be much more responsive than other vendors – in terms of response time as well as how helpful the response was for what we needed.

Although both applications are currently geared around email, with a little elbow grease you can build a best of breed marketing automation solution with their technology partners including Segment.io, Zapier, and KISSmetrics.

The winner

The two products were neck and neck, but ultimately we chose Vero because of the UI and also because the way the emails are prepared in their product suited our needs better. From the CEO on down, they eat their own dog food and use their product in very similar ways to how we use it. That makes a big difference because they see the problems and opportunities first hand. They’ve been incredibly receptive to our feedback. Bugs we reported were fixed in 24-hours or less, new features were sometimes added within days of us suggesting them.

They are a startup, and it often feels like it — pro and con. On the one hand, it’s great working with people who “speak the same language” and understand the pressure and agility a software company needs, but on the other, the product can feel rough at times. We have run into a number of issues and downtime. While those were addressed transparently and fairly quickly in most cases, downtime or long delays in sending emails can have a material effect on our campaigns and is definitely disappointing. We are hopeful that those issues will go away over time as the company becomes more established.

All that said, if you’re in the market for a modern marketing automation email marketing service that works the way you work and that you can afford, we’d wholeheartedly recommend you check out the latest crop of tools.