In this article, I’m going condense down the essentials of being an IBM Cloud Architect to less than 1500 words. This article is the big picture of the IBM Cloud (Public) offering. It’s condensed and probably over-simplified! This is a personal, opinionated perspective on the high-level knowledge needed to be an IBM Cloud Architect - it is not a formal IBM document and has not gone through review - so it’s based on my experiences (If it conflicts with formal documentation, announcements, etc. you should assume the error lies here). Others will have their own perspective. YMMV. I’ll include a lot of links for further reading, so please follow them as needed.
Caveats and Assumptions
A quick history lesson: until recently, this article would have been titled “Learn to be a Bluemix Architect…“. Bluemix was originally IBM’s PaaS platform. As of October last year, Softlayer (IBM’s IaaS) platform was merged into Bluemix to create one combined offering. To recognise the widening scope of IBM’s cloud offerings, Bluemix has recently been renamed IBM Cloud. In this article we’ll refer to “IBM Cloud”, but you’ll still find a lot of webpages, documentation, and other collateral referring to Bluemix.
This article will be focusing mostly on the PaaS components of IBM Cloud only, since that is typically how we would encourage new application construction. We’re also going to be thinking only about the IBM Cloud in its Public cloud form-factor (it’s also available in a Dedicated form-factor where it’s available for a specific customer).
There is a distinction between cloud-native applications (also called born-on-the-cloud) and applications that are to be migrated to the cloud. We’re focusing only on the former here.
Learn about the 12-factor principles. They are important for building cloud applications. In particular though, the ones which cause controversy and confusion compared to the “old” on-premise way applications were typically architected are Processes, Concurrency, and Disposability.
At its most fundamental level, there are three pieces to the (PaaS) IBM Cloud Platform:
Compute Models - this is how you develop and run your own code, and there are three you should be interested in for PaaS applications: IBM Cloud Functions (formerly called OpenWhisk), Cloud Foundry, and the IBM Container Service (based on Docker/Kubernetes).
Services - also sometimes (but technically incorrectly) called the Cloud Foundry services, these are services that you can configure and use to add additional functionality to your application. They come in a variety of different categories, including Data and Analytics, DevOps, Integration, IoT, Mobile, Security, Watson (aka Cognitive or AI) etc.
DevOps Toolchains - these are sometimes considered Services, but I logically separate them. This is basically functionality to allow for automated deployments, and other DevOps capabilities, in particular targeted the Compute Models above.
In general, the way you deploy code into each compute model differs. For example, in IBM Cloud Functions you create actions. In Cloud Foundry, you deploy applications. We will call these units of code individually compute model instances (some folks might refer to them as microservices, but that’s an architectural pattern which we will cover later).
IBM Cloud Functions
This is the most abstract of all the compute model types. The basic idea is that you construct actions by providing code that runs in response to triggers (for example, a RESTful request). The Cloud Function runtime takes care of deciding when to provision a server to run your action based on the trigger being fired. In practice, actions are provisioned within 100s of milliseconds. This model charges for code run based on seconds of execution and GBs of memory consumed, so it is particularly suitable for bursty, occasional or unpredictable variable-volume workloads. For more information, start here.
Cloud Foundry is historically the compute model that’s been part of IBM Cloud the longest. It provides a reasonable compromise between “out-of-the-box” developer-friendly behaviour (it’s relatively easy to deploy your code into a Cloud Foundry runtime and get it going), but you do need to think about individual instances of each Cloud Foundry ‘application’, and how many you have - particularly important for reliability (failover) and scalability. For more information, start here.
IBM Containers Service
IBM Containers service is a Docker and Kubernetes-based way of implementing your applications’ code. Docker is a containerization technology which allows you to package your application together with its dependencies, and Kubernetes is a container orchestrator that builds on top of Docker to provide facilities to manage your containers more easily. For more information, start here.
IBM Cloud Services
The IBM Cloud services are a set of pre-built services which exist on the IBM Cloud Platform to enable you to accelerate development of applications. The charging models (plans) available depends on the service you use. It’s not an official tool but you can find out a great overview of all the services available here.
Regions, Organizations and Spaces
IBM Cloud is available in four different geographic regions: US-South (aka Dallas), UK (aka London), Germany (aka Frankfurt), and Australia (aka Sydney). Each of those regions is largely completely separated from each other. However, some caveats you should be aware of:
Most simple solutions that don’t have high uptime requirements should probably just run in a single region. This makes things way simpler. But of course this does make you susceptible to issues that are isolated to that region.
In general, solutions that require very high availability should run in multiple regions. This means you should be either aiming for passive resilience (here, we are calling that Disaster Recovery - DR), or active resilience (in other words cross-region HA - meaning that the application is always running actively in multiple regions). To achieve either of these requires a cross-region load balancer (e.g. Akamai or Dyn) and the application to be architected in such a way that it can handle this. Both DR and cross-region HA are outside of the scope of this article, although if you pick the right components (a eventually consistent database such as Cloudant, and remove state from application runtimes) cross-region HA can be achieved.
Security is generally broken down into “data in transit” and “data at rest” - considering securing/encrypted data over the network, versus stored in a database.
Security - Data in Transit
In general, data in transit discussions are generally fairly straightforward - you want to ensure all connections in the entire system are secured with HTTPS (HTTP over SSL, aka TLS). In general, most of the core Cloud Services expose HTTPS endpoints, and you should make sure you use these. You also want to make sure any connections between your compute instances are HTTPS secured (in general, this is straightforward for Cloud Foundry as all connections are HTTPS by default).
Security - Data at Rest
You also need to think about Data at Rest security (in other words, whether data is encrypted). This is obviously particularly relevant to the database services. For example, with Cloudant, data is encrypted at rest. For other services, the answer is more complex.
You need to think about component-to-component authentication (meaning both between compute model instances and IBM Cloud services) is secured on a case-by-case basis. In general, follow the following guidelines:
- Most of the primary IBM Cloud Services provide an authentication mechanism out-of-the-box (usernames/passwords or at least an API key). Understand how it works and use it. In most cases, you can dynamically inject the credentials into the compute model instance. For example, see here for an example of how that works with Cloud Foundry.
There are approximately over 100 services in IBM Cloud, and many are important. Some of the most key are:
Cloudant - the “primary” NoSQL database for IBM Cloud. Arguably the most feature rich on the platform.
API Connect - API management solution. In particular, some of this functionality is also exposed directly through IBM Cloud Functions and Cloud Foundry, which provides a very straightforward and lightweight way to secure access to those endpoints.
Secure Gateway - for solutions which need to consume on-premise data, this is a straightforward way to build a secure tunnel from IBM Cloud to the on-premise system.
In general, cloud-native applications should be scaled horizontally. IBM Cloud Functions should handle this “automatically” be provisioning new instances on-demand. For Cloud Foundry, investigate and understand the Auto-Scaling service. For Kubernetes, add extra instances of a container/pod.
Some Other Things to Think About
You also want to think about architectural patterns for cloud development. One of those is understanding microservice development. For now we’ve been mostly ignoring this, and simply referring to compute model instances. However, there are patterns emerging for treating those specifically as microservices with well-defined RESTful interfaces. You can find out more information here and here.