Welcome back to another installment of Reasons to Deploy in the Cloud! In this series of posts, I'm discussing some reasons for choosing a cloud platform. Previously I've talked about managing costs, and the power of scaling, and ease of management. In this post, I want to step back a bit and talk about integration between cloud applications.
Cloud applications are everywhere
Most businesses and individuals are already using cloud-based applications as part of their daily routine. Email, social networking, and office applications are commonly cloud-based. Your doctor's office likely uses a cloud-based electronic health records platform. Many companies use a cloud-based customer relationship management, such as Salesforce. Nearly everything recreational on the mobile web, from games, to streaming media and networked VR, is cloud-based.
What you may or may not have noticed, is that many of these common cloud-based applications (think Gmail, Office365, etc.) expose some of their functionality for other apps to use. For instance, you can often use your user name and password from one application, such as Twitter or Google, to sign in on other apps and websites. Mobile apps frequently integrate posting content directly to social media with a click of a button. Using the features of other applications reduces the development burden to employ these features.
Cloud application synergy
This exposure of functionality is commonly referred to as an API, or Application Program Interface. You're probably familiar with the UI, or user interface, of an application: the buttons and fields that allow you to interact with it using a keyboard, mouse, or touchscreen. An API is a way for other programs to use those same interactions in an automated way.
The design of modern applications tends to follow a two-tier approach. The first tier is the User Interface, which in turn calls upon the second tier, the API, to make "requests" of data and return that data for presentation in the UI tier. This allows one "backend" for the application to power multiple "frontends" such as web, mobile, and desktop applications. It is also easy to allow other applications to make use of these backend services.
(Pictured below: A two-tier application architecture using the cloud. Source: Google App Engine Blog)
A well-designed cloud app will take advantage of this synergy and leverage existing functionality while adding something back to the ecosystem. This is mutually beneficial; The "host" apps become more pivotal and gain traction, the "client" apps get enhanced functionality from someone who already made it work. Exposing your application to third-party use in this way moves it into the Software as a Service (SaaS) space.
Cloud applications play nicely together
You might be thinking that nothing mentioned here can't be done without the cloud. Consider that our previous benefits of scaling and management are critical when you've exposed some functionality to outside applications. If use of your API catches on, you may suddenly find yourself with a deluge of new users, helping drive your revenues, but demanding more resources. Your cloud application can confidently leverage other APIs to help offload processing and offset some of the cost of development and infrastructure, because availability is part of what you're delivering.
Given these challenges and opportunities, I think it’s safe to say that cloud applications are well-positioned to interact with each other. I hope you find this helpful when thinking about how you can leverage other APIs in your cloud deployment, and how you can add something back to the ecosystem.
Next week we'll be blogging and posting to social media from the AWS re:Invent Conference in Las Vegas, NV, currently the largest annual showcase of cloud technology and architecture in the world. We'll be sure to update you on highlights and emerging trends at this year's summit. After that, tune in next time as we talk about how cloud applications leverage availability and reliability to deliver 24/7 uptime and consistent performance to a global audience.