The cloud adoption in CEE is approaching a turning point. Innovative companies and CIOs are embracing the cloud in an increasing number, challenging the “wait and see” approach of their competitors.
After several years of investments in the development of the cloud by service providers, the cloud has moved beyond the hype in CEE and has become a viable option for enhancing business agility, efficiency and driving innovation in enterprise IT. Perception around the advantages and risks of the cloud are also shifting. The business value is rapidly gaining credit through the best practices provided by the increasing number of CEE implementations while traditional concerns around security and control are becoming less prevalent.
No surprise, that the outlook of the cloud market remains outstandingly positive, representing the most dynamic segment of ICT market in CEE with an average growth rate of more than 50% for the next years. However, the growth will vary among cloud service types, depending on the resonation of the service with the specifics of the CEE market. IDC expects the most dynamic uptake in virtual private cloud, as it best addresses the need of customers for control and security, while delivering the advantage of the lower costs of the public cloud infrastructure.
The IDC Cloud Leadership Forum will provide you with insight in the ultimate cloud trends and the most recent experience of enterprise cloud users through a host of industry expert, vendor and case study presentations, roundtable discussions and coffee break talks.

Key Topics

  • Beyond the Hype: The Big Picture of Cloud Computing
  • The cloud as the foundation of the next generation IT
  • Measuring ROI: Cloud Computing, Efficiency, and Sustainability
  • What would suite you best? – The Private, Public, and Hybrid Cloud Models
  • Cloud Compliance Challenges and Solutions
  • Cloud Security Concerns: Vendor Solutions and Customer Experience
  • Private cloud: the life after virtualization
  • Infrastructure Trends in the Cloud
  • Cloud-Based Applications
  • Is cloud diminishing or transforming the role of the CIO?
  • How to get the green-light for cloud form teh business decision makers?

 Who will attend

  • CIOs IT Directors
  • IT Managers and Heads of Departments
  • Facility & Operation Managers
  • IT Infrastructure Managers
  • Network Administrators
  • Purchase Managers

Event Dates and Locations:

  • BOSNIA & HERZEGOVINA , Sarajevo – February 21
  • MALTA, Malta – March 07
  • ALMATY, Kazakhstan – March 12
  • TIRANA, Albania – March 21
  • VIENNA, Austria – April 09
  • SALZBURG, Austria – April 11
  • SKOPJE, Macedonia– April 18
  • SOFIA, Bulgaria – May 16
  • NICOSIA, Cyprus – May 20
  • MOSCOW, Russia – May 30
  • LJUBLJANA, Slovenia – June 05
  • PRAGUE, Czech – September 12
  • BRATISLAVA, Slovakia – September 17
  • ATHENS, Greece – September 20
  • KIEV, Ukraine – September 25
  • BUCHAREST, Romania – September 26
  • BELGRADE, Serbia – October 10
  • WARSAW, Poland – October 15
  • ZAGREB, Croatia – October 16
  • BUDAPEST, Hungary – October 17

Hope to see you there!

As described in the last post, we will now take a look at how it is possible to architect cloud computing applications with the support of Archimate. Archimate was developed by the Open Group and it’s target is to achieve a great enterprise architecture. We will discuss each layer and figure out how we can apply this to cloud computing architectures.
A core concept of Archimate are views. Views in Archimate allows the architect to show different levels for different stakeholders. We won’t focus on that now. If you are interested, you can refer to the Archimate Documentation. We also discussed the different layers – business layer, application layer and technology layer. To model each layer, you can use different tools. I personally prefer “Archi” for this purpose. In the Screenshot below, you can see the main window of Archi.

Archimate design with Archi

Archimate design with Archi


Let us now start with some business layer concepts. In the image below you can find the business layer concepts available with Archimate.
Archimate Business Concepts

Archimate Business Concepts


Actors are individuals or departments that interact with the application. It is very similar to the UML Actor. We can also describe a Role, which is similar to an Actor but with a very specific “job”. If we build a customer support system, the Actor would be a “Support Engineer” but the Role would be “Windows Support Role”. An Actor might have different Roles, since the Role is dedicated and specialised.
Archimate Role and Actor

Archimate Role and Actor


Another important concept is the Process. In a business model, processes are key concepts since they give us an overview on the interactions associated with the Application or a Service. Processes also require triggers, which are modelled with the Event concept. A process may be realised by a Service.
 
Archimate Processes and Events

Archimate Processes and Events


These Concepts are only some of the concepts available in Archimate. However, this is only a short tutorial. The next post will be about the application layer and technology layer in Archimate.
Picture Copyright by Moyan Brenn

I am often discussing the different platforms with people and we often end up discussing the different prices. People keep on asking me how much money you have to invest for a specific number of instances. It is necessary to look up different websites and so on. I came up with the idea of creating a simple cost comparison calculator with javascript on my blog. And I can now say: here it is!
Click here to go to the Calculator.
The cost comparision calculator gives you 3 different options:

  • Calculate the best price for cpu intense applications
  • Calculate the best price for memory intense applications
  • Calculate the best cheapest instances available.

The cost comparison calculator currently compares the following platforms:

  • Amazon EC2
  • Google Compute Engine
  • Rackspace Cloud Servers
  • Windows Azure Virtual Machines

A challenge is, what to compare. Each vendor has different instance types, so a comparison is often not so easy. Therefore, I have decided to split the comparison into different challenges as described above. For the first calculation – with cpu intense applications – i’ve used the lowest available instance. Basically, all 4 instance types matched despite Google. Google offers less memory than the other instances. The cheapest instances targets targets micro instances. All vendors despite Google offers micro instances. The memory comparison targets high memory instances.  The calculation is based on available memory. The memory is aligned to the number of instances necessary. For instance, if we select 68 GB of RAM, we need one instance at Amazon EC2 but multiple instances with Windows Azure. The prices are not aligned to instances but to the sum of memory. This leads to cheaper prices when using EC2 for lower memory. I will try to adjust this in the future.
To get updates on the calculator, you can subscribe to the newsletter below.
 

YTo4OntzOjk6IndpZGdldF9pZCI7czoyMDoid3lzaWphLW5sLTEzNjA4NDQzMzQiO3M6NToibGlzdHMiO2E6Mjp7aTowO3M6MToiNSI7aToxO3M6MToiMyI7fXM6MTA6Imxpc3RzX25hbWUiO2E6Mzp7aTo1O3M6Mjc6IkNvc3QgQ29tcGFyaXNpb24gQ2FsY3VsYXRvciI7aTo0O3M6MjM6ImJpZyBkYXRhIGNvbmZlcmVuY2UgdGl4IjtpOjM7czoyMjoiTmV3c2xldHRlciBTdWJzY3JpYmVycyI7fXM6MTI6ImF1dG9yZWdpc3RlciI7czoxNzoibm90X2F1dG9fcmVnaXN0ZXIiO3M6MTI6ImxhYmVsc3dpdGhpbiI7czoxMzoibGFiZWxzX3dpdGhpbiI7czo2OiJzdWJtaXQiO3M6MTA6IlN1YnNjcmliZSEiO3M6Nzoic3VjY2VzcyI7czo1MDoiQ2hlY2sgeW91ciBpbmJveCBub3cgdG8gY29uZmlybSB5b3VyIHN1YnNjcmlwdGlvbi4iO3M6MTI6ImN1c3RvbWZpZWxkcyI7YToxOntzOjU6ImVtYWlsIjthOjE6e3M6NToibGFiZWwiO3M6NToiRW1haWwiO319fQ==

 
Click here to go to the Calculator.
 

We are almost at a point where we can get more hands-on in terms of cloud architectures. However, there is still something we have to mention prior to talk about architectures itself. Cloud Computing is not an easy thing you can achieve since it involves a lot of knowledge: you need to know about resource automation (in case you use IaaS; with PaaS it is often easier) and than you definitely need to know everything about concurrency, distributed databases, …
This complexity in a cloud environment requires us to build a cloud architecture not only on some “core technologies”. An architecture needs to be planed in detail. It is also important to figure out how you want to iterate in an project or how you deploy your software once there are upgrades or bug fixes. But how is it possible to achieve an architecture that is detailed but still gives us the possibility to show the architecture to different stakeholders? CXOs need a more abstract model as their focus is on deciding whereas a software developer needs a lot of details. The short answer is: there is no easy solution for that. The long answer: we have to learn additional tools.
In the next few blog posts, we will look at Archimate and UML for a high-level architecture.
As we need to address different stakeholders with each stakeholder needing a different level of detail, we need to “layer” our architecture. A first hint for that can be found with Archimate. Archimate basically knows 3 different levels for an enterprise architecture. This is described in the illustration below:

Archimate Layers

Archimate Layers


Archimate knows 3 main layers. Let us brief look at each layer and figure out how each layer can be applied to cloud computing architectures.
Business Layer
The Business Layer is the most abstract layer. This layer allows us to model everything that is related to the business functions and processes. In the business layer, we define the business processes, business actors, different services and general interactions.
Application Layer
The Application Layer models all services that are used by the Business Layer. We also model the application components, services and interactions associated with it. We can model the inner behaviour of an application in this layer and combine our application components with other application components. This leads to SOA – which we will discuss later on in detail.
Technology Layer
The Technology Layer is the lowest layer. We define all infrastructural elements on this layer. This might be some IaaS or PaaS components. We can use this layer for cloud computing architectures to model all external services and instances.
As already mentioned earlier in this post, we will look at each layer in the next posts and will also model some examples.
Picture Copyright by Moyan Brenn

To find out about the Cloud Architectures we want to use, it is necessary to know the characteristics of distributed systems. Another important aspect we should consider looking at are the aims of cloud systems. If we know what aims and characteristics are, it might be easier to build a software architecture for the cloud. However, each implementation requires different approaches since each system is different from each other.
Let us start with the characteristics of cloud systems.
Cloud computing systems have a characteristic, that it is a sum of many systems (instances), but it feels like a single system for the end user. This means that it is transparent for end-users and end-users typically don’t see how many servers are involved. End users might even believe that this is running on a single server (but it is not like that). End users should not be confronted with the challenges architects/developers have to face when building a SaaS-Application. Just imagine Facebook, Twitter or Flickr: end users don’t really care about distribution, they simply want to use that platform. This means that our application has to look like a single software and hide the challenges we face for distribution.
A cloud computing system typically consists of different components. Components are various things such as instances, services, … If we build a distributed system, we have to utilise different instances with different roles. Some roles might host the website, other roles might do some background work. Different components is often implemented by SOA (Service Oriented Architectures) which is described later.
Different components as described above have to communicate with each other. Communication can be done with various technologies such as messaging. This requires the use of a message buffer.
Users of a cloud computing system can use the system in a transparent and consistent way. If a user travels, the system should represent the same state as it did before traveling. If the user works on a presentation for a client and saves the presentation, it should look absolutely the same when the user arrives at the customer’s site. Consistency is a challenge we often have to deal with in the Cloud and we will focus on that in a later post.
Cloud computing systems have to be extendable. If we have a SaaS-Application, it might serve 90% of all use-cases, but what happens with the 10% it can’t serve? It should be extented by additional services. If we look at a very important platform – Salesforce – it can be extended by a PaaS-Platform named “force.com”. To achieve extensibility, the platform must offer well-defined interfaces for potential consumers.These interfaces are typically served via an API.
The last characteristic we want to focus on is that distributed systems are often using a middleware. This middleware abstracts things from the operating system and serves interfaces to handle common things. We can see this with PaaS, where the middleware spans a large number of virtual instances. However, we simply don’t care about the operating system that is under the middleware.
Picture Copyright by Moyan Brenn

As referenced in the last post, the book “the art of scalability” provided a very good approach to cloud architectures or what has to be done. They also define some other great principles, resulting in 12 design principles for software architectures. Most of the principles are very interesting for cloud computing as well.
1. N+1 Design

There should be at least one additional System. Normally you should have 3 Systems. Premise: one System for me, one System for the Customer and one System for the Errors

2. Design for Rollback

Applications should always be able to be downgraded. It should be easy to downgrade a System in case of an Error.
3. Design to be Disabled
It must be necessary to disable a System or Parts of it, if there are problems. However, the overall System should not be effected by this.

4. Design to be Monitored

Not only IO or CPU Performance is important, it is more about  „intelligent“ Monitoring. We want to know the following:
  • When does the System act different as normal?
  • What future loads will I have?

 
5. Design for Multiple Live Sites

Backup and Recovery Centers should also carry parts of the load. If you have additional datacenters, you should use them for load, not just for recovery.

6. Use Mature Technologies

No Beta or CTP Versions but use versions that are stable.
7. Asynchronous Design
Asynch operations are more error-prone. However, they are harder to test.

8. Stateless Systems

Statefull Systems affect the system performance in a negative way and make scalability harder.
9. Scale Out, Not Up!
Scaling should be intelligent. Build a smart architecture that reduces load! Adding more Servers doesn‘t always solve the problem!

10. Design for at Least Two Axes of Scale

Divide Systems in different Parts. Scale Horizontal and vertical!
11. Buy When Non Core
Only use core competences that are already in the company. If it is not a core competency, buy it!

12. Use Commodity Hardware

High-End Hardware is more expensive
Picture Copyright by Moyan Brenn