Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Using Vendor Provided AMIs vs. Deploying Your Own Applications from AWS

DZone's Guide to

Using Vendor Provided AMIs vs. Deploying Your Own Applications from AWS

Here are some factors to take into consideration when deciding if you should build your own stack or use a third-party company.

· Cloud Zone ·
Free Resource

Discover a centralized approach to monitor your virtual infrastructure, on-premise IT environment, and cloud infrastructure – all on a single platform.

This article explores some of the typical considerations one should bear in mind when deciding between an AWS marketplace pre-baked AMI from the likes of Jumpbox or Bitnami, or the do-it-yourself approach of deploying applications on top of raw AWS services.

Time-to-Market Considerations

AWS offers a wide variety of AMIs developed by third party vendors that provide a wide range of software stacks such as LAMP stacks, or commonly used open source applications such as SugarCRM, Moodle, Redmine or Wordpress. Pre-baked AMIs help users quickly launch the required applications with only a few clicks. The pre-baked AMIs typically come with the EC2 instances, EBS, databases such as RDS and ELB load balancing configured and optimized by experts so that the software works well together.  This approach saves users a lot of time and effort and enables them get up and running utilizing the software faster.

Control, Flexibility and Competence Building Considerations

There are certain factors that must be evaluated before selecting this option rather than building and deploying your own stack and applications using raw AWS services.

As vendor AMIs have pre-installed and pre-configured software, it can at times result in less control and flexibility and make it harder to modify according to a user's needs. An example of this is that pre-baked AMIs oftentimes come with a fairly larger EBS volume (typically 10 GB+).  One can always resize using snapshots later; however, it would be nice if there was an option to select the EBS size upfront while procuring the AMI. Arguably a self-setup will help one learn more about the underlying infrastructure and software application enabling one to better tweak, configure and tune post-deployment.  

The roll-your-own approach is usually slower and more error prone with a lot of manual configuration needed. Using the raw AWS services to deploy and setup an application or stack, however, is not without its advantages. This approach enables one to learn and build competence and confidence to customize software settings going forward. Frequently, software applications such as SugarCRM and stacks such as LAMP require a lot of post setup configuration such as the addition of plugins and add-ons. The pre-baked AMI will typically require quite a bit of post-deployment tweaking for your specific needs anyway so why not get this setup the way you want it from the get go.

Cost Considerations

Another consideration is the cost of vendor AMIs vs. those of the roll-your-own approach.  The cost of vendor AMIs are set by the vendor and their aim is to turn a profit. A careful cost analysis can derive that in certain cases using the vendor AMIs can as one would expect be more costly when compared to using the roll-your-own approach using raw AWS services. Using raw services to build applications can arguably help one stay in the free tier.

An example is the comparison between SugarCRM vendor AMI and manual SugarCRM setup with raw services. The AMI can cost from $0.03 to $3.11 EC2 per hour depending on the instance type, charges for EBS volume and additional taxes, whereas the same software solution can be built up on mainly EC2, EBS and RDS free of cost using the free tier or at a very low cost if not using the free tier.

Similarly, Trac AMI by Bitnami has a pre-configured Trac with all its required stack. However, using raw services can give you the option of using any web server supported by Trac, multiple configuration of modules and plugins options that can improve performance and also option of using various database engines bringing more flexibility and control in your infrastructure.

Conclusion

In the end, it very much depends on the approach and goal of an organization behind their procurement decision. If time to market and ease of deployment are of prime consideration and giving up some control and flexibility putting up with the default configuration is not a major concern, then the pre-baked option is likely the way to go. If, however, more control and flexibility is paramount for your organisation, then taking the extra time to deploy apps using raw services is likely a better option.

Learn how to auto-discover your containers and monitor their performance, capture Docker host and container metrics to allocate host resources, and provision containers.

Topics:
aws marketplace ,aws ec2 ,cloud ,ami ,third party vendor ,roll your own approach ,cost ,time to market

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}