The essentials of being an IBM Cloud Architect
I’m a Solutions Architect in IBM’s Cloud Garage. In the Garage, we apply a variety of principles that are drawn from the worlds of Agile and Lean to get customers to experiment, learn, and deliver successful projects on the IBM Cloud Platform. I work with customers on a variety of projects across a variety of industries, especially focused on IBM’s Public Cloud platform.
In this article, I’m going to condense down the essentials of being an IBM Cloud Architect to less than 1500 words. This article covers many of the topics I end up discussing with IBM customers regarding IBM Cloud, and it’s based on my experiences (if it conflicts with formal documentation, announcements, etc. you should assume the error lies here) and a presentation I gave at IBM Think 2018. YMMV. I’ll include a lot of links for further reading, so please follow them as needed—this article is meant, of course, to just get you started.
Caveats and assumptions
Until 2016, this article would have been titled “Learn to be a Bluemix Architect.” Bluemix was originally IBM’s PaaS platform. As of October 2016, 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 was renamed IBM Cloud. In this article I’ll refer to “IBM Cloud,” but you’ll still occasionally find webpages, documentation, and other collateral referring to Bluemix. Much of that still applies.
This article will be focusing mostly on the PaaS components of IBM Cloud since that is typically what we focus on for new application construction. I’m also going to be thinking only about the IBM Cloud in its Public cloud form-factor, not Dedicated or Private Cloud. Also, there is a distinction between cloud-native applications (also called born-on-the-cloud) and applications that are to be migrated to the cloud. I’m focusing only on the former here.
For more information on cloud-native, see "Cloud-Native: A Complete Guide."
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 Cloud Kubernetes Service (based on Docker/Kubernetes).
Services: Also sometimes (but misleadingly) 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 consider them logically separate. This is functionality to allow for automated build, test, and deployment of your code, plus other DevOps capabilities.
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. I 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 I will cover later).
IBM Cloud Functions
This is the most abstract of all the compute model types. 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, but it is increasingly used for entire applications. 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 Cloud Kubernetes Service
The IBM Cloud 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. To learn more about how Docker and Kubernetes are related, check out this video: “Kubernetes vs. Docker: It’s Not an Either/Or Question.”
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) that are available depend 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 five different geographic regions: US-South, US-East, UK, Germany, and Australia. Each of those regions is mostly completely separated from each other.
Most simple solutions that don’t have high uptime requirements should probably just run in a single region, which is much 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 (HA) should run in multiple regions. This means you should be either aiming for passive resilience (here, I am 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 (for example, IBM Cloud Internet Services) 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 (an eventually consistent database such as Cloudant and remove state from application runtimes) cross-region HA can be achieved.
Security: Data in transit
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.
In general, data-in-transit discussions are 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 (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’ll need to do your research.
You need to think about component-to-component authentication (meaning between both compute model instances and IBM Cloud services) and how it is secured on a case-by-case basis. 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 over 100 services in IBM Cloud. I don’t have enough space here to cover anywhere near all of them, but some of the most key services include the following:
Cloudant: The “primary” NoSQL database for IBM Cloud. Arguably the mostfeature-richh on the platform.
API Connect: An 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” by provisioning new instances on-demand. For Cloud Foundry, investigate and understand the Auto-Scaling service. For Kubernetes, add extra instances of a container/pod.
Other things to think about
You can find a great (unofficial) jumping-off site with other links to learn more about IBM Cloud here. In the Cloud Garage, we help customers be successful with the IBM Cloud Platform. You can find out a lot more about our method and approach, as well as how to engage with us, here. If you would like to see how we can help you, schedule a free-four hour consultation.