Architecting your solutions to cloud

Share this post:


When I was in the US two weeks ago, I was woken up by a ring at midnight. One of my friends asked me a very urgent question about his solution architecture in Amazon EC2. He is developing an online chatting application for iOS, where he has earned millions of dollars in the past three years. This was his first time to deal with an architecture which includes both iPhone side applications and ‘back-end’ services.

The scenario reminds me, as a thought leader level architect in IBM, that there are a lot of things to think and to do in a cloud world. When we are using cloud as a service, there will be three players in the game:

  • Services Creator, who offers the ‘cloud-side’ service as a standard one
  • Services Provider, who provisions the standard service to consumers
  • Services Consumer, who use the standard service in his/her solution

There would be different architecting skills in the roles. For example, the Services Provider would design a complex architecture to manage, provision and maintain the solution infrastructure and billing systems.

In this blog, I will take the view of Services Consumer. The responsibilities and architecting techniques would be used in solutions.

Basic Architecting

When we are stepping into any solution architecture, we will focus on the components, connections and such.

There are three major tasks before we will design traditional architecture:

  • Requirements, we need to know what to produce (the functional requirements) and how to product (the non-functional architecture)
  • System context, we need to know the boundary of our solution and what resources are already there
  • Reference architecture, we need to develop from a mature status. We are not to re-invent the wheels at each time

Then we will go to design phase. In a solution, we always talk about ‘one system, single architecture, and multiple viewpoints’. There are two major viewpoints in the architecture:

  • Component model, CM will set up a view to satisfy the functional requirements mostly. The components will represent what will be developed in the area
  • Operational model, OM will set up a view to the operational (or real deployment) of the nodes. The nodes will contain the components. The non-functional requirements will be meet here mostly

There are also a lot of cross-cutting viewpoints like security and performance. There is a detailed description in IEEE 1471.

In the end, the solution architect should perform a validation process to make sure the solution is doable.

Are the things still the same in cloud world?

Discussion on architecting cloud solution

From a consumers’ view, the architecture is still there.

If we consider the IaaS/PaaS model, the services provider only provides ‘node’ without components. It means, the cloud nodes are some part of architecture but not architecture.

Although there may be SaaS in the cloud world, but it is very difficult to think about the solution will be ‘one-fit-all’ type. For example, a consumer needs to upload their own data and define their own processes in ERP/CRM solutions. That makes the difference of an IT world.

Let us have some discussion on the three phases of cloud solution.

1. Before

  • Requirements, the requirements are still there. The requirements are for the solution, not for the capabilities of cloud!
  • System context, this may be tricky. The nodes in cloud may become ‘in scope’ nodes so you should consider the ‘connections to cloud’. In this situation, there would be some challenges to identify what the connections would be:

a) Connections between cloud computers and consumer own networks

b) Connections between users and cloud computers

c) Connections between existing party or third party systems and cloud computers

Although the connections may all exist on the Internet, there would be challenges of implement the connections using different access mechanism such as VPN technology or mobile technology

  • Reference architecture, there are little reference architecture available of how to implement integrations with the cloud. For example, in my friend’s case, they put their entire infrastructure in EC2 with Amazon’s interconnections. But there are no references how the interconnections are working. This may result in some unexpected results. I highly recommend him to make the transactions as simple as possible to minimum the risks of such uncertain behaviors.

2. Design

  • Component model. Actually, the functional part is independent to meet business requirements. You could develop all your components in your garage PCs and deploy them to cloud. There are just some hints in design such components:

a) Keep the connections between components simple. It will be good to use tiers and layers to isolate components so that the connections between components could be aggregated as connections between function clusters

b) Use deployment unit to integrate the tiered and layered components. The deployment unit could include multiple components (or tiered functions of components) so that the architecture in cloud could be simple

c) Consider some transaction manage components in the solutions to connect cloud and legacies

  • Operational model. This is a nightmare for architects. How could I implement a non-functional requirements (like performance) in an uncertain nodes (most cloud services providers don’t like SLA, while IBM SmartCloud Enterprise provides some commitments). The advantage is pay as you go and unlimited resources to help you on this.

I told my friend a short term solution on the iPhone services. He could develop a very small daemon to watch the performance from iPhone side. When there is some latency, he should automatically apply a new virtual computer in EC2 and clone the application components there. Then he could fix or restart (or even release) the previous computer. He developed this daemon in one hour and he used another three days to find the bugs in his previous applications – inefficient use of connections pool.

3. Validation

There is a two-sided sword in validation cloud architecture. In one side, it is difficult to estimate the behavior of a node in cloud, so it is difficult to draw a mathematical conclusion; in the other side, the architect could use simulation method to keep a testing environment in cloud which could be used to validate the whole architecture on pay-as-you-go base! The simulation may be more practical for quality assurance to accept the whole solution. And more, the simulation could be a market demonstration for sales person.

So far I think architecting the solutions with cloud nodes are similar to architecting traditional solutions. Is this too ideal?

A Multi Tenancy House – Further discussion on architecting skills

The cloud is running in ‘multi tenant model’. There is one infrastructure shared by different tenants. The tenants don’t know each other and do not disturb each other too. Is that good?

In an architect’s view, multi tenant may result in uncertain services levels. One example is if all tenants take bath together, could the house supply enough hot water with good pressure? Obviously, no.

So in real world, the architect should know how the services provider will provision resources. For example, one of my customers asked to move a core banking system to a cloud which will have 5,000 physical servers and 20,000+ virtual servers. Unfortunately, there are no qualified cloud provide in China could leverage such a big effort without disturbing other tenants.

Another interesting topic is what if two tenants get married. This may result in some social business. For example, a game on cloud would like to use the database of a SNS application. The traditional way may be the game step out of the house and build a ladder to the SNS application’s window. Is there a better one?

If the SNS application could integrate itself with the cloud as a services creator, the game would enjoy the in-house lobby to access the other’s room. This would be more efficient.

Some Words

It will be a huge topic to discuss architecture:

  • Cloud architecture
  • Integration with cloud
  • Providing services to cloud
  • Disaster recovery in cloud

I just posted some ideas here to reflect the architecting value of IBM Services. Although there will be cable TV in every house so that the users don’t need to move the antenna up and down, the cable workers and architects are still there to provide the cables from some cloud to the users’ home.

As a senior architect, I feel the works in cloud world for me would be more challenging and innovative. The architecting skills and methodologies would be adhered to and would be improved.

More stories

Why we added new map tools to Netcool

I had the opportunity to visit a number of telecommunications clients using IBM Netcool over the last year. We frequently discussed the benefits of have a geographically mapped view of topology. Not just because it was nice “eye candy” in the Network Operations Center (NOC), but because it gives an important geographically-based view of network […]

Continue reading

How to streamline continuous delivery through better auditing

IT managers, does this sound familiar? Just when everything is running smoothly, you encounter the release management process in place for upgrading business applications in the production environment. You get an error notification in one of the workflows running the release management process. It can be especially frustrating when the error is coming from the […]

Continue reading

Want to see the latest from WebSphere Liberty? Join our webcast

We just released the latest release of WebSphere Liberty, It includes many new enhancements to its security, database management and overall performance. Interested in what’s new? Join our webcast on January 11, 2017. Why? Read on. I used to take time to reflect on the year behind me as the calendar year closed out, […]

Continue reading