Cloud application recipes
A 3-step layered recipe
The value of patterns in software development, architecture, and operations has been recorded extensively over the years. Examples include The Open Group's Architecture pattern discussion in TOGAF and Kyle Brown's discussion of Patterns at all levels in the context of run time patterns.
In this article, you'll learn about a new type of patterns called recipes. You can use recipes to assess candidate applications for migration to or implementation in the cloud. These applications can run exclusively in the cloud or in a hybrid model, where some components are run in other cloud platforms or in traditional environments.
Recipes simplify the time and effort to analyze your applications and determine how best to deploy the application into your IaaS or PaaS cloud platforms. Using the three basic building blocks outlined below, you can assess each application to define what is required and how best to align your application to cloud systems and services. What's more, you can extend the basic patterns with two additional layers of services; recipe-specific ecosystem services and general ecosystem services
The core pattern, or recipe, provides insights into how to construct your application or component from a set of runtimes and services. They're not boilerplates (that implies a specific combination of specific services), but instead a set of instructions on how to combine general service types. A boilerplate is more like a frozen pizza or a packaged cup of Ramen Noodles than a recipe.
There are three general types of recipes explored in this article, each of which has specific subtypes. You'll learn the different recipe types and the service types that support each recipe type. First you need to know three concepts that relate to the type of systems that you can build in the cloud. You'll see why this is important when the first recipe is defined. The system types are:
- Systems of record – A system of record is one in which you record information about real-world objects or events. If in your application you have complex data about people, events, and things in a persistent store, then you are probably building a system of record.
- Systems of engagement – A system of engagement is one in which you interact primarily with people, instead of other systems. If your application is designed to access existing data or at most allow simple changes to existing data, you're probably building a system of engagement.
- Systems of insight – A system of insight is perhaps the hardest of the system types to understand. If your system exists to answer questions about the past, or to try to predict the future in some way, then you are most likely building a system of insight.
This is important because each of these three system types corresponds to a specific combination of runtimes and services that are unique to that type. In other words, these are our first recipes. But, a recipe consists of a core set of ingredients. For example, a system of record usually requires a database to meet its specific functional and non-functional requirements. What you can vary are the additional ingredients that you fit to the particular problem at hand; much like a recipe in cooking instructing you to "season to taste."
In fact, the simplest recipe is the one for a system of record. After reviewing dozens of examples of systems of record that have either been documented on developerWorks or that we've built through the IBM® Bluemix Garage, we've found that recipe to be:
System of Record = Runtime + Data Source + (Optional) Gateway
Figure 1. Example data sources
What does this all mean?
A runtime is the first piece in IBM® Bluemix, that could either mean a Cloud Foundry Instant Runtime (such as the Liberty Buildpack), or a Docker Container, or VM that can host your application code.
A data source is the next component. It could be any one of the SQL choices in Bluemix (like DB2 as a Service or the PostgreSQL by Compose Service) or any of the NoSQL choices such as IBM® Cloudant® or Redis by Compose.
The gateway is the part that might be more difficult to understand. Some (but not all) systems of record rely on multiple data source types, some of which might be behind corporate firewalls. So a gateway could include a service like API Management or even the secure gateway to gain access to those data sources. Likewise systems of record can also have front-end gateways. If your runtime is built as an asynchronous service, you'll need a gateway like the Message Hub or the IBM® MQLight service to allow other systems to communicate with it.
A system of insight shares one thing with a system of record, a data source. The data source is often the only commonality. Here's the recipe for a system of insight:
System of Insight = Data Source + (Optional) Visualization + (Optional) Analytics Tool + (Optional) Data Movement
It's worth examining the two new types of services introduced. An analytics tool is a service that helps you perform specialized analysis of your data. Examples of an analytics tool include IBM® BigInsights® for Apache Hadoop, Apache Spark, or even IBM® DashDB™. A visualization is a type of service that helps your user see the results of your analysis. It could be in textual form, like a report from Embeddable Reports. Or, it could be in a visual tool like IOT Real-Time Insights. Finally, you might need to move data in and out of different data sources in a system of insight – that's the job of a data movement tool like IBM® DataWorks.
With a system of engagement, you'll always have a runtime, and often a gateway, but you might or might not have a data source. If your system of engagement is caching data locally, you might have a data source to act as a cache, but you shouldn't be storing any data permanently in a system of engagement – that's the job of a system of record. So the simpler recipe for system of engagement is:
System of Engagement = Runtime + [Data Source as Cache] + [Gateway]
In this example it seems like everything's optional! That's not much help. The real differentiation comes in on the next layer – when you consider the more specific recipes that use services from the recipe-specific ecosystem.
Figure 2. Logical recipe types
The next layer are services in the recipe-specific ecosystem that includes the systems or services used by one or more specific recipes in order to fully function within a testing or production environment in addition to the base recipe.
Recipes often come in specific subtypes that help you decide both what core services and recipe-specific ecosystem services you need:
Systems of interaction are divided into web systems of interaction and mobile systems of interaction:
- A web system of interaction would possibly use recipe-specific ecosystem services like session caching and single-sign on
- A mobile system of interaction could use recipe-specific services like push notification, mobile quality assurance and mobile security
We also often see Internet of Things systems of record that send and receive messages through the IOT gateway. Often that is combined with a system of engagement that allows users to interact with the information that is stored in the data store by that system of record.
Finally, systems of insight can be divided into historical systems of insight and realtime systems of insight
- Historical systems of insight uses techniques like table pivoting available in DashDB.
- Realtime systems of insight can use techniques like streaming analytics or Apache Spark
The systems or services in this layer can be divided into two groups. Those include systems or services to:
- Enable operational success. This includes services such as monitoring, load balancing, and caching. For example, when selecting cloud services for a web system of interaction (SOI) recipe you might find you need session caching, load balancing or automatic scaling.
- Interact with the application to support functional requirements. operations. The interactions can use multiple protocols (SOAP, REST, JDBC, etc). The availability of these systems or services vary by environment (Dev, QA, Prod) and, in some cases are represented by published APIs or virtual services.
The final type of services are general ecosystem services that support the software development, delivery, and release lifecycle. For organizations deploying to hybrid, traditional or mainframe environments, this ecosystem provides the systems and services for multiple environments in the application delivery lifecycles. For example, if you deploy your web application in Bluemix public then you would select BlazeMeter or LoadImpact to test the performance of the application. And if you are developing a cloud-native application for deployment onto Public Bluemix, choose to use the DevOps Services Delivery Pipeline to build and deploy your application into different stages. Contrasting, if you develop applications with hybrid workflows that deploy to traditional on premises environments and to one or more cloud (IaaS, PaaS) platforms, then use UrbanCode Deploy for application deployments and full stack provisioning in the cloud platforms.
Understand available capabilities
When using this approach you might want to qualify your application and pattern by determining if your application is cloud ready. A good framework to follow in this evaluation is "Top 9 rules for cloud applications" (developerWorks, April 2014).
You should also have an understanding of your cloud provider or traditional platform capabilities, especially the provided services you hope to leverage. Many providers have websites, such as IBM's cloud services.
Understand the capabilities you have for integrating your platforms if you intend to operate some of your application across platforms in a hybrid model. A good example is APIs and hybrid cloud integration.
Asses the systems or services offered by a cloud provider, across providers or hosted on premises. For example, the blog "UrbanCode with Bluemix for Hybrid Cloud Deployment" demonstrates a common capability across delivery pipelines for hybrid and traditional platforms.
Building a Recipe
It's best to apply the recipe to each application and then look for repeatable ecosystems to categorize your applications into common patterns. This should be performed iteratively and only introduce new requirements or services when needed.
- Step 1: Build out your recipe. Experiment and determine what the right runtimes and services are for your core recipe.
- Step 2: Does your application need recipe ecosystem services to implement recipe-specific functionality or meet NFR's of your recipe core? If so, add recipe-specific ecosystem services.
- Step 3: Does your application need ecosystem services to fulfill the NFR's of your solution in the areas of maintainability, performance or reliability, or security? If so, add in general ecosystem services such as one or more of the DevOps Services or the Security Services.
The figure below shows an example Bluemix recipe. It includes a core recipe of the Java run time, Cloudant DB, Secure gateway, and CUPS for connectivity to additional on premises data source. It also includes recipe-specific and general ecosystems in the form of DevOps open tool chain, auto-scaling analytics, and message hub.
Figure 3. Example Bluemix recipe
In this article, you learned about architecture patterns you can use to plan migration of your applications to the IaaS or PaaS cloud platforms. The three step layered approach provides a means to define your core and ecosystem patterns that will enable you to define the run time topologies and necessary cloud services for your applications. By using this approach, you will reduce your time and effort to plan your migration and reduce complexity when moving multiple applications with similar recipe patterns.