Build, Buy or Rent? Shave Application Development Time and Cost With Cloud Services
When we sit down to design a cloud-based application, we go beyond the traditional “build vs. buy” analysis for each component of the solution. In the cloud, our mindset is “build, buy or rent.” Let me explain.
We know we could build every feature of a custom application from the ground up. We get ultimate control of the result, but often the cost or timeframe to do so is prohibitive. So as developers, we look to incorporate pre-built components to speed things along. Not only that, we strive for better functionality by incorporating specialized components that others have already invested far more resources in than we ever could for a single application. As a simple example, who would ever write a graphing engine from scratch with so many great ones out there? So, build is rarely the whole story.
What about buy? I think of “buy” not in a strict monetary sense, but as a moniker for code or components that get pulled into the physical boundary of your application. This includes both open source components and commercial products, in the form of source code you pull into your project, or binaries you install and run with your applications’ infrastructure. We all do this all the time.
But the cloud brings a third option to the table: rent. I define this as a service you integrate with via some API, which runs outside your application’s physical boundary. This is where smart developers see an opportunity to shave more time and cost off of projects while maintaining—or even increasing—the quality of functionality.
Both buy and rent have their place, and we often employ both strategies on a single project. What I like about renting is:
- Often even less effort to integrate than a “buy” component
- As the service is improved by its publisher, you can often take advantage without rebuilding your application
- Someone else owns the infrastructure to run that service
- Cost usually scales with usage
Of course there’s a flip side to each of these points. Arguments to buy include:
- You can sever your reliance on a third party, which can be a valid concern if the publisher of the service is new, small or lacking market adoption
- Sometimes there is more ability to customize (though this depends on the nature of the component or service)
- Some integrations are too complex or intimate to achieve through a loosely coupled API approach
With all that as context, here is our current Top 10 List of services we integrate into (i.e., rent) into our clients’ cloud applications:
- Postmark http://postmarkapp.com - for application email, both outbound and inbound
- OLark http://www.olark.com - an online chat client for customer service
- Twilio http://www.twilio.com - an API for integrating SMS and voice into applications
- Arrow Payments http://www.arrowpayments.com - secure payment processing API (hint: we wrote the API!)
- Red Gate Cloud Services http://cloudservices.red-gate.com - backup scheduling for databases and storage on both Azure and AWS
- Pingdom https://www.pingdom.com - a health monitoring service to proactively notify when application components go offline
- SmartyStreets http://smartystreets.com - postal address verification and validation
- Google Analytics http://www.google.com/analytics/ - an oldie but a goodie; we connect this to virtually every application we write
- Google Maps https://maps.google.com - still the standard for adding maps after all these years
- Google Charts https://developers.google.com/chart/ - an interesting alternative to buying a charting engine -- let Google render charts remotely on behalf of your application
Using these services saves not only time and cost, but also means that we can change direction easily, incorporating client and customer feedback into future iterations. Certain features not functioning seamlessly? Swap them out. Need more functionality? Customize aspects or change services.
Next post, I’ll get into the software components we often buy to integrate.