Posts

Mario Meir-Huber

Cloud Computing Architectures: application roles

As described in an earlier post, another concept for cloud computing architectures is the concept of roles. But what exactly is a role? A role is something that shares common functionality. If we talk about a web shop, this web shop might consist of different roles such as:

  • Product presentation role
  • Shopping cart role
  • Order processing workflow role
  • …

The initial question of this is: isn’t this called SOA (Service oriented architectures)? The answer is: no. It is very similar to SOA and basically derives a lot of it’s concepts from SOA but it is rather a “SOA of SOA”. A role might contain one or more services, but a service is covered by exactly one role. Let us think about the shopping cart: an architecture for the shopping cart might hold different services. The role itself would be the shopping cart role with services for:

  • Shopping Cart modification Service
  • Checkout Service
  • Payment Service

A role collects different services and makes it easier for us to understand the way how an application is built. With SOA, we can go more into detail and give a better overview for those that have to implement the platform at the end. Different roles should be able to be scaled independently from each other to achieve great elasticity in the cloud. Furthermore, a role should only be in charge of similar tasks. If we think about the shopping cart again, we can definitely say that services in that role are somewhat similar. The illustration below shows how different roles can be built.

Application Role Separation in the cloud

Application Role Separation in the cloud


With the separation of different roles, it gives us more flexibility to built our platform more reliable. If the platform experiences an outage, less important roles might not receive any compute but the business critical roles will still receive the available resources. Therefore, it is possible to built a matrix on how important each role is and adjust scaling/elasticity to this matrix.
Different Roles are more important for others. In the web shop sample, an important role is the shopping cart since it is the place where the platform generates revenue. Not so important (in the case of an outage) is the comment functionality. If there is a shortage of resources or some serious issues with our platform, the platform can select to disable the comment role and use the now free resources for the shopping cart. However, this approach requires a smart system that can deal with the prioritisation of roles.
Picture Copyright by Moyan Brenn

/0 Comments/by
Mario Meir-Huber

Cloud Computing Architectures: Application layer and technology layer with Archimate

As described in our previous post on cloud computing architectures, I would like to continue with the architectural approach given with Archimate. Archimate comes with two more layers, the application and the technology layer. The Application layer has some core concepts we can use for cloud computing architectures:

  • Services. Services are provided by our platform and expose and endpoint for other applications or services. This is often implemented by a web service. With a service, data is usually exposed to consumers or operations are made available. A typical service could be a customer service, that exposes customer data.
  • Interfaces. Interfaces are built for interoperability between different services or applications. A service typically provides an interface to the consumers. Consumers use the Interface but the implementation is done at the service side.
  • Application Component. An application component is a software application, that provides some way of interaction, maybe via a service. We could use an application component to retrieve data or so.
  • Data Object. This basically describes an object that contains data. This is typically a row in a database.

Of course, this list is not complete. For a more detailed description please refer to the Archimate Documentation. In the following sample, we will model a very simple application layer case.

Archimate application layer concepts

Archimate application layer concepts


In the above sample, I modelled a very abstract customer service. This service is used by a shopping system. The service itself queries Salesforce.com to retrieve the data via the Salesforce API. Salesforce.com is represented as a application component in our architectural sample. The customer service itself uses some data, which is contained in the customer data object.
The lowest layer for Cloud architectures is the technology layer. In this layer, we can model different instances – or let’s say roles (I will describe the concept of roles later on). This is basically useful when using Infrastructure as a Service (IaaS) or Platform as a Service (PaaS). With the technology layer we model the overall components used by our platform in an infrastructural way. Core concepts are:

  • Nodes. A node is normally an instance in Archimate, e.g. a single server. However, we use the node for a complete role. Imagine Netflix would model each of their servers with an individual node – they might end up having such a complex model that nobody would understand the model. A individual role (such as the front ends) are represented by a Node.
  • System Software. A system software is a software that fulfils elementary tasks. A sample for a system software is the apache web server or PHP, MySQL, … System software usually runs on a node. It is also possible to have more system software installed on a node.
  • Network. Individual Roles communicate with each other – either within the Role or with other roles. Therefore, some type of transportation must be available. This is represented by the network.
  • Communication Path. The communication path is another way of communication. This is not the network itself but it is a more abstract way of communication. Normally, the communication path could be represented by a message queue.

In the following sample, I tried to model a very basic architecture for an IaaS-Platform based on the concepts introduced above.

Archimate technology layer concepts for cloud computing architectures

Archimate technology layer concepts for cloud computing architectures


In the sample above, we have three major roles for our cloud platform architecture: front-ends, database and backend. The Front-end is one or more (if load balanced) virtual instances running Linux. On each instance, there is Apache and PHP installed. This is also called a stack, the shortcut for this stack is “LAP”. Normally, we would also use MySQL, which would be named “LAMP” (Linux, Apache, Mysql, Php). However, since our architecture should be scalable, I decided to outsource the database to another role. This gives us the possibility to scale the front-end and database independently. On the database role, we instal MySQL and some sort of reporting services for business intelligence. These two roles are connected via a LAN. The third role is a backend role. On this role, there is a custom application with OpenXML installed. This backend role basically processes data and returns documents. The communication isn’t done directly but it is done via a message queue. I will also explain this in a later post why I don’t communicate directly.
Picture Copyright by Moyan Brenn

/0 Comments/by
Mario Meir-Huber

Cloud Computing Architectures: High-Level architecture with Archimate

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

/0 Comments/by
Mario Meir-Huber

Cloud Computing Architectures: how to build and plan your cloud

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

/1 Comment/by
Mario Meir-Huber

Cloud Computing Architectures: aims and characteristics of cloud systems

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

/0 Comments/by
Mario Meir-Huber

Cloud Computing Architectures: 12 Design principles

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
/0 Comments/by
Mario Meir-Huber
,

Strategies for Cloud Computing Application Deployment

As already mentioned in the last post, Application deployment in the Cloud is not an easy task. It requires a lot of work and knowledge, unless you use Platform as a Service. The later one might reduce this complexity significantly. In order to deploy your Applications to an Infrastructure as a Service Layer, you might need additional knowledge. Let us now built upon what we have heard from the last post by looking at several strategies and how they are implemented by different enterprises.
Some years ago before joining IDC, I worked for a local Software Company. We had some large-scale deployments in place and we used Cloud Services to run our Systems. In this company, my task was to work on the deployment and iteration strategy (but not only on that ;)). We developed in an agile iteration model (basically it was Scrum). This means that our Team had a new “Release” every 2 weeks. During these two weeks, new Features were developed and bugs fixed. The Testing department checked for Bugs and the development Team had to fix them. We enforced daily check-ins and gated them. A gated check-in means that the check-in is only accepted if the Source Code can be compiled on the Build Server(s). The benefit of this was to have a working Version every morning as some started early (e.g. 6am) and others rather late (e.g. at 10am). Before starting with that, our Teams often ran into the error of having to debug bad code that was checked in by someone the day before. Different teams worked on different Features and if the team decided a feature to be final, it was merged to the “stable” branch. Usually on Thursdays (we figured out that Fridays are not good for deployment for various reasons) we deployed the stable branch. The features initially get deployed to a staging system. The Operations Team tests the features. If a feature isn’t working, it has to be disabled and removed from the stable release. Once there was a final version with working features, we deployed them to the live system. This usually happened on Friday evening or Saturdays. Over the years, the Development and Operations Team got a real “Team” and less features had to be removed from the staging system due to errors/bugs. My task was to keep the process running since it was now “easy” to forget about the rules once everything seems to run good.
Want to hear more about Application Deployment? Subscribe to the Newsletter:

YTo4OntzOjk6IndpZGdldF9pZCI7czoyMDoid3lzaWphLW5sLTEzNTQ1MTgzMTIiO3M6NToibGlzdHMiO2E6MTp7aTowO3M6MToiMyI7fXM6MTA6Imxpc3RzX25hbWUiO2E6MTp7aTozO3M6MjI6Ik5ld3NsZXR0ZXIgU3Vic2NyaWJlcnMiO31zOjEyOiJhdXRvcmVnaXN0ZXIiO3M6MTc6Im5vdF9hdXRvX3JlZ2lzdGVyIjtzOjEyOiJsYWJlbHN3aXRoaW4iO3M6MTM6ImxhYmVsc193aXRoaW4iO3M6Njoic3VibWl0IjtzOjEwOiJTdWJzY3JpYmUhIjtzOjc6InN1Y2Nlc3MiO3M6ODU6IkNoZWNrIHlvdXIgaW5ib3ggbm93IHRvIGNvbmZpcm0geW91ciBzdWJzY3JpcHRpb24uIFBMRUFTRSBBTFNPIENIRUNLIFRIRSBTUEFNIEZPTERFUiEiO3M6MTI6ImN1c3RvbWZpZWxkcyI7YToxOntzOjU6ImVtYWlsIjthOjE6e3M6NToibGFiZWwiO3M6NToiRW1haWwiO319fQ==

 
A very advanced environment is Windows Azure. Windows Azure is Microsoft’s Cloud Platform and was usually designed as a PaaS-Platform. However, they added several IaaS-Features so far. In this post, I will only focus on the PaaS-Capapilities of Windows Azure. There are several steps involved:

  1. Full Package with Assemblies gets uploaded
  2. If a new Package is added, a Staging Environment is started. There is now the possibility to Test on that Staging Environment
  3. Once the Administrator decides the Package to be „safe“, Staging is switched to Production
  4. New Roles with the new Binaries are started
  5. Old Roles that still have Sessions are up and running until all Sessions are closed
Deployment for Windows Azure PaaS

Deployment for Windows Azure PaaS

This is a very mature deployment process and solves a lot of problems that are normally associated with deployment for large-scale Cloud Systems.
Facebook described their process for deployment very clear:
  1. Facebook takes advantage of BitTorrent
  2. New Versions of the Software gets added to a Tracker
  3. Each Server listens to the Trackers
  4. Once a new Version is available, it is downloaded to the Server
  5. The Server then unloads the current Version and Loads the new one
  6. Old Versions always stay on the Server
  7. Easy Rollback
Any Questions/Issues on deployment? Post your comments below.
/0 Comments/by
Mario Meir-Huber
,

Data in the Cloud: SQL? NoSQL!

In recent years, one trend has become increasingly popular: NoSQL Databases. Databases built without relations, but made for high scalability. But is it really that “good” to go for NoSQL Databases? Doing so means removing the consistency that SQL Databases offers. Isn’t that a big tradeoff or is it worth going for more NoSQL Databases? What are the opportunities, advantages of NoSQL and why should you definitley keep an eye onto it? Join me for a tour on NoSQL. A world without relations, no joins and pure scalability!
A key disadvantage of SQL Databases is the fact that SQL Databases are at a high abstraction level. This is a disadvantage because to do a single Statement, SQL often requires the data to be processed multiple times. This, of course, takes time and performance. For instance, multiple queries on SQL Data occur when there is a ‘Join’ operation. Cloud Computing environments need high-performing, and highly scaleable databases.
Normally, SQL Databases have the advantage over NoSQL Databases to have better support for Business Intelligence. In most cases, Business Intelligence is not necessary in NoSQL Databases. If we look at the big Platforms in the Web like Facebook or Twitter, there are some Datasets that do not need any relations. The risk in that is the fact that there might be some kind of “inconsistency” across various  tables. The challenge for NoSQL Databases is to keep the data consistent. Imagine the fact that a user deletes his or her account. If this is hosted on a NoSQL Database, all the tables have to checked for any data the user has produced in the past. With NoSQL, this has to be done by code.
A major advantage of NoSQL Databases is the fact that Data replication can be done more easy then it would be with SQL Databases. As there are no relations, Tables don’t necessary have to be on the same servers. This allows a NoSQL Database a much more performant way to partition the data. This fact also applies to tables itself. If a table gets very big, this Table can be distributed over various servers easily. Again, this allows better scaling than SQL Databases. Don’t forget: scaling is one of the key aspects in Cloud Computing environments.
To fully understand why NoSQL Databases will be the future for Cloud Computing data, it is important to understand how Cloud Computing works. Cloud Computing Plattforms are made for a great number of people and potential customers. This means that there will be millions of queries over various tables, millions or even billions of read and write operations within seconds. SQL Databases are built to server another market: the business intelligence one, where less queries are executed.
Another disadvantage of SQL databases is the fact that there is always a schema involved. Over time, requirements will definitely change and the database somehow has to support this new requirements. This can lead to serious problems. Just imagine the fact that your application now needs two extra fields to store data. Solving this issue with SQL Databases might get very hard. NoSQL databases support a changing environment for data and are a better solution in this case as well.
However, it is up to the Use-Case to identify if you want a NoSQL approach or if you better stay with SQL

/0 Comments/by
Mario Meir-Huber

The art of Cloud Computing Scalability

With Cloud Computing, we often hear that “Scaling” is very easy. In most cases, it is actually like that! You can simply go and add new virtual machines/instances on demand, with only some seconds or minutes to be provisioned. However, there are some other factors that improove Scalability or limit scalability. The reason for that is simply: if your software is built a way that dissalows scaling, you can never use the benefits of the cloud. Just because you can scale your instances on demand, it might not mean that your software allows that!
Imagine the following scenario: your Web Application stores data like images in the File System. Suddenly, you have increased need for performance as your business grows. So what would you do? Exactly, simply add a new instance. After a while, your users and customers complain that they can’t find their images all the time. After a while, you figure out that the Load Balancer directs to either one of the virtual machines you are using. One machine contains images (stored on the file system), the other doesn’t (as it is the new one). If your software was built in a SoA Style, you might have used a Service instead of the File System. To really scale out your Software, you now need to invest a significant amount of time into re-engineering.
First of all, we have to get rid of some confusion: when talking about Scalability or Scaling, people often talk about “Elasticity” as well. But what is the difference between those two terms? Aren’t they the same at all? There is a significant difference between the term “Scalability” and “Elasticity”. When we talk about Scaling, we talk about the possibility to add new instances and remove instances. This is just the possibility itself. Elasticity means that we have exactly the power we need for our services. If we need, for instance, 4 virtual machines, we can scale them up or down, but we still have to do some work to achieve that (e.g. starting a new instance in the AWS Management Console). If we talk about elasticity, it means that we have exactly the power of 4 machines when they are necessary and we don’t even have to care about how they get provisioned – it is automated! The goal for your software should be to enable elasticity, not just scalability.
Whenever we talk about Scaling, we mainly talk about the factor “Hardware” but forget about other important things to scale out, such as:
–Websites
–Applications
–Teams
–Organisations

Scaling Software Teams

Scaling Software Teams


If you add more and more instances as your business grows, you might also add more features to your application. However, more features also means that there is more code to maintain, more bugs to eliminate and more updates to deliver. Therefore, you need to increase your team size, which isn’t easy at all. Just because you add 2 new developers to a team of 2 developers (double the number of Dev’s) you simply don’t double the performance. Most of the time, the performance is even below the original performance for the first weeks, until they become a “real team”. But in all cases, there is a significant overload on communication and organisation involved, which can’t be solved that easy. Before taking care of scaling your Software, you might consider how to scale your teams that are in charge of delivering your software.
In the next posts, we will go deeper into different technologies and architectural styles that enable your software to scale out, not just up.
The Image used as Header is licenced under the Creative Commons Attribution-Share Alike 3.0 Unported license by José Ramón Polo López.
/0 Comments/by
Mario Meir-Huber

Design Guidelines for Cloud Computing and Distributed Systems

Infrastructure as a Service and Platform as a Service offer us easy scaling of services. However, scaling is not as easy as it seems to be in the Cloud. If your software architecture isn’t done right, your services and applications might not scale as expected, even if you add new instances. As for most distributed systems, there are a couple of guidelines you should consider. I have summed up the ones I use most often for designing distributed systems.
Design for Failure
As Moore stated, everything that can fail, will fail. So it is very clear that a distributed system will fail at a certain time, even though cloud computing providers tell us that it is very unlikely. We had some outages [1][2] in the last year of some of the major platforms, and there might be even more of them. Therefore, your application should be able to deal with an outage of your cloud provider. This can be done with different techniques such as distributing an application in more than one availability zone (which should be done anyway). Netflix has a very interesting approach to steadily test their software for errors – they have employed an army of “Chaos Monkeys” [3]. Of course, they are not real monkeys. It is software that randomly takes down different Instances. Netflix produces errors on purpose to see how their system reacts and if it is still performing well. The question is not if there will be another outage; the question is when the next outage will be.
Design for at Least Three Running Systems
For on-premise systems, we always used to do an “N+1” Design. This still applies in the cloud. There should always be one more system available than actually necessary. In the cloud, this can easily be achieved by running your instances in different geographical locations and availability zones. In case one region fails, the other region will take over. Some platforms offer intelligent routing and can easily forward traffic to another zone if one zone is down. However, there is this “rule of three,” that basically says you should have three systems available: one for me, one for the customer and one if there is a failure. This will minimize the risk of an outage significantly for you.
Design for Monitoring
We all need to know what is going on in our datacenters and on our systems. Therefore, monitoring is an important aspect for every application you build. If you want to design intelligent monitoring, I/O performance or other metrics are not the only important things. It would be best if your system could “predict” your future load – this could either be done by statistical data you have from your applications‘ history or from your applications‘ domain. If your application is on sports betting, you might have high load on during major sports events. If it is for social games, your load might be higher during the day or when the weather is bad outside. However, your system should be monitored all the time and it should tell you in case a major failure might come up.
Design for Rollback
Large systems are typically owned by different teams in your company. This means that a lot of people work on your systems and rollout happens often. Even though there should be a lot of testing involved, it will still happen that new features will affect other services of your application. To prevent from that, our application should allow an easy rollback mechanism.
Design No State
State kills. If you store states on your systems, this will make load balancing much more complicated for you. State should be eliminated wherever and whenever possible. There are several techniques to reduce or remove state in your application. Modern devices such as tablets or smartphones have sufficient performance to store state information on the client. Every service call should be independent and it shouldn‘t be necessary to have a session state on the server. All session state should be transferred to the client, as described by Roy Fielding [4]. Architectural styles such as ROA support this idea and help you make your services stateless. I will dig into ReST and ROA in one of my upcoming articles since this is really great for distributed systems.
Design to Disable Services
It should be easy to disable services that are not performing well or influencing your system in a way that is poisoning the entire application. Therefore, it will be important to isolate each service from each other, since it should not affect the entire system’s functionality. Imagine the comment function of Amazon is not working – this might be essential to make up your mind about buying a book, but it wouldn’t prevent you from buying the book.
Design Different Roles
However, with distributed systems we have a lot of servers involved – and it‘s necessary not to scale a front-end or back-end server, but to scale individual services. If there is exactly one front-end system that hosts all roles and a specific service experiences high load, why would it be necessary to scale up all services, even those services that have minor load? You might improve your systems if you have them split up in different roles. As already described by Bertram Meyer [5] with Command Query Separation, your application should also be split in different roles. This is basically a key thing for SOA applications; however, I still see that most services are not separated. There should be more separation of concerns based on the services. Implement some kind of application role separation for your application and services to improve scaling.
There might be additional principles for distributed systems. I see this article as a rather “living” one and will extend it over the time. I would be interested is your feedback on this. What are your thoughts on distributed systems? Email me at mario.mh@cloudvane.com, use the comment section here or get in touch with me via Twitter at @mario_mh

  1. Azure Management Outage, Ars Technica
  2. Amazon EC2 Outage, TechCrunch
  3. The Netflix Simian Army, Netflix Tech Blog
  4. Representational State Transfer (REST), Roy Fielding, 2000
  5. Command Query Separation, Wikipedia
This post was originally posted by Mario Meir-Huber on Sys-Con Media.
The Image displayed for this post is Licenced under the Creative Commons and further details about the picture can be found here.

 

/1 Comment/by