22 July 2019

The evolving hybrid integration reference architecture

Hybrid Cloud: reference architectures for Power Systems

Best practices for deploying your apps in the cloud

Determine the best deployment for your apps on a cloud infrastructure

As a developer, you probably hear a lot about new technologies that promise to increase the speed at which you can develop software, as well as ones that can increase the resiliency of your applications once you have deployed them. Your challenge is to wade through these emerging technologies and determine which ones actually hold promise for the projects that you are currently working on.

IBM Cloud Paks in 2 Minutes

No doubt, you are aware that cloud computing offers great promise for developers. However, you might not know about the areas where this technology can provide value to you and your projects. You also might not know good practices to employ when implementing a project in the cloud. This article explores the types of cloud computing systems available, and provides guidelines that can help you with real-world application deployments on top of a cloud infrastructure.

2019 CIO Think Tank: Pathways to Multicloud Transformation

Choose between IaaS, PaaS, and SaaS

When people begin discussing cloud computing, they are generally speaking about one of three possible deployment choices for application code: infrastructure as a service (IaaS), platform as a service (PaaS), or software as a service (SaaS). Which one is right for your project depends on your specific needs for the code base that you are working on. Let’s examine each one of these cloud choices.

Infrastructure as a service (IaaS)

IaaS is a platform where an infrastructure is provided for you. With a click of a button, you can spin up virtual machines hosted by a provider with an operating system of your choice. The vendor providing the machine is responsible for the connectivity and initial provisioning of the system, and you are responsible for everything else. The vendor provides a machine and an operating system, but you need to install all of the software packages, application runtimes/servers, and databases that your application requires. Generally, IaaS requires that you have a team of system administrators to manage the system and apply firewall rules, patches, and security errata on a frequent basis.

Pro: You have complete control over every aspect of the system.
Con: You need system administration knowledge or a team of system administrators to maintain the systems, since you are responsible for their uptime and security.

Modernize existing z/OS applications using IBM Cloud Private and IBM Cloud

Platform as a service (PaaS)

PaaS is a fairly new technology stack that runs on top of IaaS and was created with the developer in mind. With the PaaS platform, everything is provided except the application code, users, and data. Typically, when using a PaaS, the vendor maintains the application server, databases, and all of the necessary operating system components, giving you time to focus on the application code. Since the vendor manages that platform for you, it is often hard to open up ports that are not specifically called for the application server, runtime, or database in use. PaaS also provides features that are specifically meant for applications, including the ability to scale the application tier up based upon the user demand of the application. In most platforms, this happens with little-to-no interaction from the developer.

Pro: PaaS provides a complete environment that is actively managed, letting you focus on your application code.
Con: Developers are often restricted to certain major/minor versions of packages available on the system so that the vendor can manage the platform effectively.

Pathways to Multicloud Transformation

Software as a service (SaaS)

With the SaaS platform, everything is provided for you except the users and the application data. The vendor provides the application code and the developer has limited access to modify the software in use. This is typically not a choice for deploying custom applications, as the vendor provides the entire software stack. Hosted web email clients and hosted sales automation software are two good examples of how SaaS is used.

Pro: The entire stack is provided by the vendor except the application users and the associated data.
Con: You have limited control over the hosted application and it’s often hard to integrate external workflows into the system.

IBMBusiness Resiliency Services - IBM Cloud Resiliency Orchestration

Which should you choose?
As an application developer, you should choose PaaS, because that the infrastructure is managed for you, so you can focus on your application code.

Scale your application
As mentioned previously, PaaS provides scaling out of the box for most languages and runtimes. However, as a developer you need to be aware of the types of scaling offered and when it makes sense to scale horizontally or vertically.

Portable Apps across IBM Kubernetes Service and IBM Cloud Private

Vertical scaling
Vertical scaling refers to a type of scaling that has been the default choice for decades. This type of scaling refers to the notion that to handle load, you simply use larger systems. This is one of the reasons why there are servers in place today with a terabyte of RAM and a massive number of CPUs and cores to serve a single Java® application. Typically when using vertical scaling, a single large system is used to handle most or all of the application requests from the users.

Horizontal scaling
With horizontal scaling, the application load and requests are spread over a group of smaller servers that are typically behind a load balancer. As a request from a user is made, the load balancer sends the request to a server and then manages the session state across the cluster of servers. There are usually two types of horizontal scaling to use to ensure the best possible experience for the users of your application: manual and automatic scaling.

Manage hybrid IT with IBM Services for Multicloud Management

Manual scaling
With manual scaling, you specify that you want the application to scale up to handle increased traffic when you know you have an upcoming event that will increase application demand. For example, if you know that you are going to be running a marketing campaign to attract more users to your application, you might want to proactively add additional servers to your cluster. Most PaaS providers allow you to accomplish this task with a simple command.

Automatic scaling
With automatic scaling, you specify conditions where your application will automatically scale without any human interaction. This condition can be based on such things as the number of concurrent HTTP requests your application is receiving, or the amount of the CPU that your application is using. This enables the developer to automatically add new servers to the load balancer when the demand for the application is high. Automatic scaling provides a truly hands-off approach to scaling while ensuring that demand from the users is met in a timely fashion. Automatic scaling is crucial when you have unplanned use of your application due to certain circumstances. For example, you might get your mobile application featured on an application store for a short period of time when your back-end services reside in the cloud.

Lecture 15: Cloud Computing

Which application scaling should you choose?

As a developer, you should choose a platform that allows for both manual and automatic horizontal scaling of your application.

Consider application state
Most cloud providers that provide a PaaS want you to start with green field development, which means that projects that are not affected by the constraints of prior work. Porting existing or legacy applications to the platform can be a challenge, mainly because the file systems in place are ephemeral in nature and do not allow for saving application state or resources on the file system.

This restriction is why you might hear that you need to think about future applications as being stateless. To receive the benefits of an infrastructure that resides in the cloud, you need to employ stateless application design in your projects. To achieve that, take into account the following practices for new applications:

Allow the application server or container to maintain the session state of the user across the cluster instead of relying on the file system.
Do not store files or user assets on the physical file system of the server that your code is deployed to. Instead, consider using a cloud-based storage service and delivering assets through the provided REST API for the storage service.
Use a database for storing assets related to a user if you do not have access to use a cloud storage API.

Creating Production-Ready, Secure and Scalable Applications in IBM Cloud Private

Which application state should you choose?
For green field applications, you should design applications that are stateless, which means they do not store user assets or resources on the file system. For legacy or existing applications, choose a PaaS provider that supports both stateful and stateless applications.

Choose a database for cloud-enabled applications

Almost all applications being created today rely on a database of some type on the back end to store and retrieve information to be presented to the user. When developing applications for the cloud, you must also take into consideration what databases you will be using and where those databases should be located. Should the database be hosted on the same servers as the application, or is it better to house the database on a separate server or container?
In many cases, an application relies on information that’s stored in a database that resides behind a corporate firewall, while the application front end is deployed on the public cloud. When this is the case, you have a couple of options for effectively accessing the information that you’ll need to present to the user on the front end.

  • Option 1: Choose a provider that allows you to open up a remote VPC connection back to your database.
  • Option 2: Communicate to the database through a set of authenticated REST services deployed on the infrastructure that have access to the data.

Both of these options have inherent security risks that you need to consider when connecting to a database behind a corporate firewall from an outside cloud application. When this is the case, your best option is to select a cloud PaaS vendor that allows you to deploy your applications on a non multi-tenant environment.

Data and AI for hybrid cloud and multi cloud world

If your application code does not need to connect to an existing corporate database, the number of options that you have are almost endless. I suggest that you deploy your database in the same geography/datacenter/region as your application code but on different containers or servers than your front-end application code. Use this option to scale the database independently of the web tier. Also, be sure to choose a database that scales quickly and easily regardless of whether it’s a SQL or NOSQL database.

Deploying Kubernetes in the Enterprise IBM

Consider multiple geographies

One of the great benefits of cloud computing is that you can deploy your application infrastructure throughout the world with little or no up-front cost. For example, deploying an application that has servers in both North America and EMEA has traditionally incurred a huge up-front cost to purchase and provision hardware and data centers. With an infrastructure that resides in the cloud, you can effortlessly deploy your application across as many geographies as your vendor supports. For simple applications that only have a limited number of users, this is not required. However, having access to deploy code in multiple geographies is critical to winning customer satisfaction by locating the application code as close to your target audience as possible.

Throw in the ability to manually or automatically scale your application across different geographies, and you’ll have a really interesting value proposition on your hands by incurring a lower cost than deploying a traditional IT infrastructure.

Accelerate AI Deployments with IBM Cloud Pak for Data System

Which cloud provider should you choose for multiple geographies?
Choose a cloud provider that enables you to both deploy and scale your application infrastructure across multiple geographies throughout the world to ensure that your audience has a fast and responsive experience while using your application.

Create and use REST-based web services

As you can see, deploying your application code in the cloud provides many benefits — and one crucial benefit for high-demand applications is the ability to scale out the web and database tiers independently. That being said, it is also good practice to separate your business logic into web services that your front-end code can consume. Use this practice to scale out the web services tier independently from both the database and the front-end code. Separating your application logic from the presentation tier opens new doors for technologies that you might not have considered in the past, such as creating a single-page application using a language like Node.

Accelerate Digital Transformation with IBM Cloud Private

Implement continuous delivery and integration

DevOps seems to be the latest buzzword that is gaining a lot of attraction across enterprises. To get ahead, you should probably start looking at and implementing both continuous integration and delivery on your next software project. When deploying applications to a cloud-based infrastructure, make sure you have workflows in place on your existing build system so that code can be deployed across the different environments. Fortunately, most of the more popular build systems provide plugins for some of the top cloud providers today, making it easy to configure your deployment rules based upon the correct permissions of who has access to deploy code to each environment. If you are not currently using a build system for your development team, start using one now!

Hybrid Cloud Explained

Which cloud provider should you choose for continuous integration and delivery?

Choose a cloud provider that meets all of the requirements above with the added feature of integrated continuous integration and continuous delivery (CI/CD) tools on the platform. The provider you choose should allow you to deploy your own build system or have the ability to easily integrate with existing systems that reside outside of the cloud platform.

Avoid vendor lock-in

If you take one thing away from this article, I hope this is it: While many cloud providers provide great-looking proprietary APIs that reduce the amount of code or work that you have to do, you should avoid them at all costs. This is nothing more than a simple ploy to get you locked into their ecosystem while making it extremely hard to move your application to another provider or to your own data center running in-house. To avoid these custom APIs, stick with tried-and-true technology stacks across your application, including the database tier, storage tier, and any micro service endpoints that you might want to create. While the up-front investment can be a bit higher than using a proprietary solution out of the box, your technical debt is greatly reduced, which can save you money and time in the long run.

Public, Private & Hybrid Clouds

Develop locally or in the cloud

As developers, we often code applications on our local system and then, when we reach a work milestone, we move our code to the team’s development environment. Most developers wish they could develop on a daily basis with an infrastructure that resembles production as closely as possible. That goal can often be challenging due to the system administration overhead incurred to provide each developer with a cluster of machines.

Now that PaaS is available, all developers should begin to develop and deploy their code in the cloud. Most integrated development environments (IDE) provide plugins to streamline the process and make it feel as close to developing locally as possible.

Which IDE should you choose?

Choose an IDE that provides a plugin for the cloud provider of your choice. Consider choosing a provider that provides the ability to hot deploy application code as well as the ability to enable remote debugging of your source code. Once you have selected a provider that offers these two things, you can continue to set break points inside of your IDE and step through code just as if you were deploying locally. This enables you to more quickly catch bugs that only appear when moving to a clustered environment.

IBM Cloud Direct Link provides fast, secure and reliable performance for hybrid workloads

What to look for in the coming years from cloud providers

This article focused on the current state of applications being deployed to the cloud. One thing to look for and consider this year and next is the mass-industry movement to container-based deployments — you have probably already heard about Docker and rocket containers. When selecting a cloud provider, make sure the roadmap for application migration to container-based deployments is called out clearly with a timeline that clearly defines your migration path. Also, be on the lookout for vendors that are sticking with industry-standard solutions around containers and orchestration, versus creating proprietary solutions.


Cloud computing has many benefits that you should take advantage of in your daily software development and deployment to make your software more stable, scalable, and secure. When moving applications to the cloud, consider the following guidance:

  • For application development, choose PaaS. The infrastructure is managed by a vendor, which gives you more time to focus on your application code.
  • For application development, choose a platform enabled for both manual and automatic horizontal scaling of your application.
  • For green-field applications, design apps that are stateless.
  • For legacy or existing applications, choose a PaaS provider that supports both stateful and stateless applications.
  • Choose a database that is scalable and located on a separate server or container from your application code. Then you can scale the database independently.
  • Choose a cloud provider that enables you to both deploy and scale your application infrastructure across multiple geographies throughout the world.
  • Develop using REST-based web services.
  • Choose a cloud provider that meets all of the previous requirements with the added feature of integrated continuous integrations and continuous delivery tools in the platform.
  • Avoid being locked in by a vendor.

The evolving hybrid integration reference architecture

How to ensure your integration landscape keeps pace with digital transformation

Over time, integration inevitably increases in complexity. This complexity is a result of the greater diversity of resources that we need to integrate, in ever-increasing permutations of infrastructures and platforms. Furthermore, the people who are involved in integrating systems are no longer centralized in a single technical team, but are spread throughout and beyond the enterprise.

In parallel, and in part as a result of this increase in complexity, a competing drive aims to simplify and rationalize integration. Web APIs have matured to become a common platform and language-agnostic way for applications to communicate. Infrastructure is ever more virtualized and containerized to free run times from hardware and operating system specifics and enable elastic workload orchestration. Teams are learning to more effectively join their development and operations staff together and automate from build to deployment for rapid release cycles.

IBM Cloud Private

The challenges are truly hybrid in many different senses of the word. Locations, teams, methods, platforms, and more are continuously diverging. The architecture of the integration across this hybrid environment is evolving at a rapid pace.

We explore how hybrid integration has evolved. First, we examine how the scope of integration has changed with the move to cloud. Next, we define the high-level characteristics of a hybrid integration capability. Then, we explain how IT is less often a central function within the organization. We continue by looking at the fundamental building blocks of a hybrid integration architecture and how integration can be productized though the API economy. Finally, we highlight how you can recognize and satisfy the needs of the digital team and improve consistency across the hybrid environment.

The extended surface area of hybrid integration
Today, the ownership boundary of an enterprise spreads well beyond its walls, encompassing IT assets across a truly hybrid environment. In this architecture, existing applications are moved to the infrastructure as a service (IaaS) of cloud providers. New applications are often built on the cloud as a platform as a service (PaaS). In line with this trend, a surge is also taking place in the use of pre-built cloud-based software as a service (SaaS).

In addition, interaction with external parties, whether customers or business partners, is increasingly automated. The degree of automation with those external parties is often a business differentiator.
Extended surface area of hybrid integration

Run Analytics Faster with IBM Integrated Analytics System

As such, any integration capability must fundamentally address connectivity across cloud boundaries. This capability must also simplify the security and management issues that it brings and embrace the standards that are evolving within hybrid architectures.

Hybrid integration is often simplistically defined as the ability to integrate on-premises systems with cloud systems. The reality for most organizations has much broader dimensions. A true hybrid integration architecture considers integration between all the owned environments, spanning on-premises and cloud environments, and whether that cloud is local, dedicated, or public. It also spans from a self-built environment to platforms to SaaS. It also must factor how the enterprise connects with its partners and customers. Hybrid integration has a vast scope. The key challenge is how to interpret that complexity and find common architectural patterns within it to help simplify the problem.

Assembling your cloud orchestra: A field guide to multi-cloud management

Hybrid integration core capabilities
At a high level, hybrid integration is a broad integration framework. It seamlessly bridges all owned environments, whether direct data sources, applications, or APIs, and can connect to them wherever they might be: on-premises, IaaS, PaaS, or SaaS.
Capabilities and scope of hybrid integration

Hybrid integration must contain broad connectivity capabilities for modern cloud-based applications and to equally critical, but older systems of record (SOR). It must have tools to simplify and accelerate productivity, such as flexible and fast mapping and transformation. From a non-functional perspective, it must also provide enterprise-grade and Internet-grade scalability, security, and resilience.

IBM Public Cloud for Power

However, although it is important to define hybrid integration as a whole, we must consider how integration needs are changing and recognize the two different audiences that are involved.

Adoption of IT by the line of business
For some years now, particularly accelerated by the mobile revolution, centralized IT has diverged into at least two different camps: often termed enterprise IT and digital IT.

Enterprise IT retains its vital role of ensuring that business-critical systems maintain their service levels and provide the type of data integrity and secure governance that are expected of core systems on which the business depends. However, this heavily regulated and controlled environment does not meet the needs of the lines of business (LOBs) who must keep the public face of the enterprise fresh with new propositions and innovations in a rapidly changing market.

LOBs have an increasing focus on requirements, such as the following examples:

Agility. LOBs need to explore and adapt, rapidly iterating over prototypes, and where necessary, failing fast and moving on to the next idea. This approach implies the use of different techniques to build more componentized applications, such as a microservices architecture. It also means increasing focus on a DevOps culture, where the distance between implementation changes and production delivery is minimized.

Scalability. If a prototype is launched, LOBs must be able to elastically scale it, moving a prototype from a handful of sponsored users to the open market, without significant additional development effort. LOBs must be able to scale the infrastructure up and down by using a simple and predictable cost model, implying use of IaaS or PaaS, and by adhering to an inherently scalable application architecture.

Latency. LOBs might also have different needs regarding the real-time responsiveness of the applications they provide. The latency that is required to create an engaging mobile experience might be significantly lower than the latency that is provided by existing systems of record. The latency might require using pre-aggregated or cached data and designing around the challenging issues of data duplication and eventual consistency. It might also require adequate traffic management to prioritize workloads.

Availability. The reputation of a primarily online business can be irreversibly damaged by even the smallest amount of downtime at the wrong moment. Proven availability is a differentiator. LOBs need applications that are designed for continuous high availability. These applications often require different approaches to resilience than you might choose for internal enterprise applications.

IBM Cloud Private

Given these requirements, you can see how shadow IT departments have arisen within LOBs and are now taking on significant new projects by using techniques that are different from the techniques that are used by central IT. These LOB IT departments are quickly moving out of the shadows and becoming recognized as the digital IT team who is responsible for creating the next generation of applications. This team often has a different culture and focus, recruiting business minded people with technical skills rather than raw technical specialists. As such, the team’s focus is on gaining revenue and market share by using rapid innovation. However, the applications that these individuals are creating represent the public face of the company. Therefore, they also require a solid technical backbone to satisfy core non-functional requirements.

Both enterprise IT and digital IT teams have integration needs. They need to integrate both within their own domains and with one another. At a high level, those hybrid integration capabilities sound similar, such as connectivity, transformation, API exposure, and composition. However, they differ dramatically in their details.

More Information:












0 reacties:

Post a Comment