An application would be something like Etsy, the marketplace for hand-crafted goods, while a component would be something like Twilio, which provides a REST-based VoIP telephony interface. The requirements for applications and components are quite different and offer different benefits and constraints. It's not out of the question that you will provide both — which means you'll need to think about how you create and operations your software offerings so that you can support both requirements.
Secret to Operating as Application Provider? Continuous Deployment
I heard Etsy CTO Kellan Elliott-McCrea speak a few weeks ago about how Etsy runs its application. His presentation was fascinating:
Every customer sees a different Etsy. Even though users interact with Etsy, what each one sees is tuned to his or her particular profile. Depending on what searches have been performed, what items have been previously purchased and personal demographics, different content is aggregated to provide a "one-off Etsy" personalized for that individual.
New services and code changes implementing fixes or new functionality are constantly being deployed. There's no "update window;" instead, hundreds of changes are made each day. Etsy is a constantly evolving application, not one that infrequently moves from one version to another.
All deployment is automatic. Etsy has built an IRC-based communication system connected to its source code management system that, when triggered, deploys one or more code check-ins to the production Etsy system. This isn't, however, a matter of an individual developer checking in code and pressing a button to deploy code into production. A designated operations person decides what to deploy and when; when that individual triggers the deployment, Etsy backend systems automatically move code into the production system. No humans need to take any action.
Every deployment can be incrementally deployed and seamlessly backed out. Etsy uses a code-flagging system to identify new code and can direct traffic percentages to servers running new code to ensure it works properly. In other words, it can test a new change on a small amount of overall system traffic to ensure it works properly and, should it not do so, can easily remove the code from servers. If tested code proves that it works properly, more servers have the flag set to expose the code, increasing until all traffic accesses servers with operational new code.
Failure of an underlying services doesn't cause the overall application to stop working. The application is written so that a failed service doesn't halt the application. Instead, the application leaves that section blank or serves up placeholder information. Under no circumstances does the application stop operating due to an underlying failure. Obviously, it's not desirable that the underlying services don't work, but it's important that the higher-level application be robust in the face of service failure.
Sign up for Computerworld eNewsletters.