Today, at the CloudOps conference in Frankfurt I talked to many users of cloud services. The discussion started around my presentation with the title (translated into English) "German and European Competitors of Amazon AWS". In the presentation I gave an overview over the competitor landscape that Amazon AWS is facing in Germany and Europe. The take-away message is: There exist great German and European cloud services that compete with Amazon AWS. However, none provides the extreme depth of the cloud stack as Amazon is doing with its huge number of cloud services. Additionally, for a given cloud service most competitors lack the feature richness Amazon is offering.
During the discussion after my talk I realized that all of users of Amazon AWS do not use only one service (such as EC2 (IaaS) or Beanstalk (PaaS)) instead most of them use five to ten or even more services (e.g., CloudWatch, CloudFront, and S3). The reason for this is that is it so easy to use another Amazon AWS service that developers or DevOps are not thinking twice before using it. The cloud services Amazon is offering are often so logically combined and interact so perfectly smooth with each other that you use automatically an additional service even that you intentionally wanted to use another one. Cloudwatch and EC2 are a good example: If you start using EC2 Cloudwatch is automatically enabled (in its basic version). If EC2 is used in a professional environment you need a decent monitoring solution to see how your instances behave (e.g., CPU utilization, and network throughput). For this CloudWatch is already active so you stick with it and built on it.
This service creep makes sure that you integrate Amazon AWS service deeper and deeper into your product and processes. This in return makes it difficult to replace Amazon AWS if you are unhappy with their service (for whatever reason). And because their is no competitor that provides the same depth of the cloud stack as Amazon AWS it is even more difficult to replace AWS. You have to go to three or four or even more cloud services providers to get the set of cloud services you need to replace AWS. This is what I call the "Amazon AWS Trap".
If I would be the VP Product Management at Amazon AWS I would be really happy about this well integrated and logically combined services that interact so smoothly. I assume this was hard work and not easy to accomplish.
From a customer point of view you have to be careful about how deep you integrate Amazon AWS into your products because replacing them can be tough. However, if you do not plan to replace Amazon AWS is makes a lot of sense to deeply integrate these services.
This text represents my personal opinion and has nothing to do with any company I associated with.
Posted by Thomas King at 23:32 2013-10-01 | Trackbacks (0) | Comments (0)
German and European Cloud Services Competing with Amazon AWS (Cloud Computing)
With the growing insights into the PRISM program the reluctance against US-based cloud services is raising on a rapid speed in Germany. Especially, from companies and individuals located in Germany my perception is that they try to avoid US-based cloud services wherever possible. For instance, the very popular German business contact networking plattform Xing just started a data privacy campaign stating that all servers are located in Germany. As sign that this is of high interest for Xing customers is that this campaign is shown on the top of the first page which you see when you log in to their service. This is just one example that services using US-based data storage or computing power are considered harmful.
Based on these developments described above I started evaluating different cloud-computing offerings based in Germany or European. I included the Europe as the data privacy laws in Europe are (mostly) similar to the German ones. As Amazon AWS is considered as one of the leading cloud service providers with a comprehensive set of cloud services I use them as a reference. In the following I summarize my experience with competitors for selected cloud services. I selected the cloud services based on my use cases.
One important finding is already that no competitor in Germany or Europe provides a similar set of services that is able to compete with Amazaon AWS. In fact, all competitors focus on one or two cloud services and leave other cloud services to other companies.
- EC2/IaaS: Many companies provide IaaS services which means (virtualized) cloud servers that can be controlled by an API. For instance JiffyBox by domainFACTORY is a service I use for a few of my projects. It runs smoothly but the size of the cloud servers is limited to 6 CPUs and 32GB of RAM. This makes JiffyBox not suitable for projects that require large cloud servers (e.g., database servers). Profitbricks is more flexible when it comes to the size of cloud servers and they provide an addional computing center in Las Vegas, USA. However, they had some stability problems during their launch in 2011/2012 so I never used them for any of my projects. My experience with Profitbricks is just based on their test accounts they provide for free. With CloudSigma my level of experience is similar to Profitbricks. However, they are located in Zürich, Switzerland so I never considered them as a proper fit. A couple of days ago I read about GreenQloud, an IaaS provider based in Iceland. The difference between them and any other IaaS provider in the list is that their cloud server product ComputeCloud is API-compatible with Amazon AWS. I just started my evaluation of these service so if you have any experience with them I would be happy to hear about it.
- The PaaS/Beanstalk area is nearly as crowded as the IaaS/EC2 area. For instance, there is fortrabbit.com from Berlin, Germany that provides PHP as a service combined with mysql-databases and memcache. Their service runs on top of Amazon AWS which actually disqualifies them from this comparison. The same is true for cloudcontrol.com which provides a Java, Python, PHP, and Ruby support but runs also on top of Amazon AWS. In contrast, Jelastic (provided by dogado and Host Europe) runs in the data center of Host Europe which is located in Cologne, Germany. Jelastic provides a huge set of programming languages (e.g., Java, Ruby, PHP), databases (e.g., MariaDB, PostgreSQL, MongoDB, and CouchDB) and premium services such as high availability and load balancing. I use Jelastic for some of my projects and I am very happy with their service even that an API to manage their PaaS infrastructure is not existing. However, this will be changed in the future as I was told by a Jelastic guy.
- Object store/S3: Object stores are provided by many hosters nowadays. For instance Host Europe is offering an object store that comes with an S3-compatible API. Also, Greenqloud offers something similar which they call StorageQloud. There also exist companies offering storage solutions based on Openstack Swift such as Internet4You. All these solutions provide the basic features I expect from a object store so I am fine with them.
- Anycast DNS-Hosting/Route53: I searched for a while but I could only find one cloud service located in Germany or Europe: ECS-Webhosting. This service looks a little bit old fashioned and it does not provide an API to control it. Additionally, it is quite expensive so I did not check it out.
- CDN/CloudFront: In the CDN area there are a few German- and Europe-based companies. For instance wavecdn.com is located in Fürth, Germany. They provide an CDN which is based on more than 10 points of presence on five continents. The CDN can be easily controlled by an API. For one of my relatively small projects this CDN worked fine. Besides wavecdn there are tv1 and cdn77 which I never used so far.
The good news is that as you can see there are German- or Europe-based competitors to Amazon AWS that provide a similar set of features. A really huge drawback is that if you go with these competitors you have to handle a group of cloud service providers. Especially, if you think about setting up contracts, managing partners, integrating services (e.g., API integration, interoperability of services), and running services (e.g., status monitoring, troubleshooting, services windows, service down-times) is by far more complex if you handle four or five providers instead one. However, if the data privacy is on risk it often makes a lot of sense to add these additional management overhead.
If you want to contact me please drop me an email at king@t-king.de.
This text represents my personal opinion and has nothing to do with any company I associated with.
Posted by Thomas King at 14:05 2013-09-07 | Trackbacks (0) | Comments (0)
DevOps: This is What Start-ups Practice (Cloud Computing)
The DevOps movement is currently getting stronger and stronger. I think this is good!
Let me quickly summarize what DevOps means for those of you who have never heard of it: DevOps is about developers not only building software but they are also responsible of running it in production. This is new in a sense that (small and big) cooperates usually divide between developers responsible for building a software and operation engineers who are in charge to run the software. These two groups have typically different priorities which are often conflictive. The operation engineers do not want to make (big) changes to software that runs without any problem while software developers have a high interest in adding new features and using new technologies to fulfill their tasks. If software breaks finger pointing typically starts because software developers say operation engineers do not support their new features and technologies. In contrast, operation engineers state developers add feature after feature and new technology without thinking about how to run these in production. They also blame software developers for not providing tools that support typically operation tasks such as monitoring or logging. To overcome this situation the DevOps movement state “you built it, you run it” meaning software developers are responsible for running their code.
Another facet of the DevOps movement is that tasks that have to be repeatedly executed are automated. This means technologies like file versioning, scripting, testing and monitoring are deployed and heavily used. This leads to easier and faster common task execution and this is typically an enabler for deploying software more often (e.g. a few times a day).
I really like the idea because from my point of view a developer is not only responsible for adding a feature but he is also responsible to think about the impact of his changes when the software runs in production. If the software developer is the guy who is responsible to run the software he makes sure his changes do not make his live troublesome. The developer makes also sure new features can be easily tested and monitored to detect if something goes wrong before the production system comes to a halt. And if something goes wrong the software developer will be in a position to update the production system quickly by using automated software deployment.
At all small companies and start-ups I was responsible for software development we lived the DevOps ideas even without knowing this movement existed. At the beginning if the team is small it is natural that no dedicated operation engineer is available. This means the task of running software is the task of the guy who developed it. If the team grows and software gets more complex the responsibility of running the software sticks with the team that developed it. So the software developer team is responsible that (1) the software which is ready for production is intensively tested and monitored and (2) the software deployment process is easy and automated. If still something goes wrong (and this will be case on a regular basis) the software development team is responsible to identify the root case of the problem and fix it. As soon as the fix is tested the new software version is deployed to production.
If I compare the ease of running software in start-ups with big cooperates I understand why big cooperates bush the DevOps movement so hard. :-)
This text represents my personal opinion and has nothing to do with any company I associated with.
Posted by Thomas King at 10:55 2013-09-04 | Trackbacks (0) | Comments (0)
What We Often Miss About the Cloud (Cloud Computing)
What we miss quite often in our (technical) discussions about the cloud is that the cloud is a means to support us to do our actual work faster and cheaper. Quite often I get the impression that technicians love the cloud because of the technical complexity and novelty of its technical solutions. So these guys try to add cloud services to any feature requirement and challenge at hand. However, this way of using cloud services is not a sustainable way because it is quite often not the best solution. For me the cloud is just a means to help me do my work faster and cheaper. Period. (And by the way it is quite often a really cool way of doing my work. :-))
Posted by Thomas King at 09:34 2013-08-26 | Trackbacks (0) | Comments (0)
Should an IT Startup Use Cloud Services? (Cloud Computing)
Recently, I had a discussion about what kind of cloud services an IT startup should use at the famous startup barbeque meeting (called Gründergrillen) in Karlsruhe. The starting point of the discussion was that a friend of mine - also a CTO of a successful startup - told me that they started to use elastic search in their product. As they are already using many Amazon AWS services I asked him if he did try out Cloudsearch. He told me that they didn't try Cloudsearch because it is too expensive. They started to run elastic search on EC2 instances they manage by themselfes. Also other search service providers (like qbox.io or found.no) did not fit his budget. I did not know anything about his use case for a search service I asked him how much money he would have to spend with Cloudsearch or another search cloud service. He told me that the smallest Cloudsearch configuration would fit his needs. Such an Cloudsearch instance costs about 80€ a month. He further told me that he installed elastic search on a set of EC2 instances that already provided mysql database services.
I was completely surprised: For $80 a month you cannot even do regular software updates, log files checks, configuring backups and all the other steps you have to do if you run your own elastic search infrastructure. And why did he run his own mysql cluster? What is the point of using IaaS cloud instances to configure and run services such as mysql and search services by yourself if you can get these services also in a managed cloud-fashion? For me as a CTO of an IT startup this is very clear: If a (professionally managed) cloud service is available for a service I have a need for I use it.
My rules of thumb to decide if I should use a (professionally managed) cloud service instead of setting up a similar service by myself are:
- Is the service a critical core service of my business that I need to adjust, enhance or expand in a way my potential cloud service provider cannot deliver it?
- Is the price of the cloud service in questions smaller or similar to the price I have to pay if my colleagues or I are spending the time to run the service in question in a similar quality (e.g., uptime, high availability, backup routines)?
This text represents my personal opinion and has nothing to do with any company I associated with.
Posted by Thomas King at 19:12 2013-08-09 | Trackbacks (0) | Comments (0)
The Difference Between a Virutal Server and a Cloud Server: API (Cloud Computing)
In the classical web hosting business we are currently seeing a trend of what many are calling cloud washing: Every product gets a “Cloud” label attached. A good example is: It is not a virtual server anymore, it is now a cloud server.
If you follow the widely accepted definition of what cloud is (for instance see the wikipedia article about cloud computing) you realize that a so-called cloud server (or formerly known as a virtual server) is only by some means a cloud product. However, at least one important property of a real cloud server is missing from many so-called cloud servers: an API to program them. If you as a user can setup, start, stop, restart, terminate or clone a virtual server by using an API it might qualify as a real cloud server.
For me as a technical guy and CTO of a startup it is very important that I can program virtual - ähm - cloud servers. This allows me to use virtual machines just like any other software library and run different workloads on them. This is also the enabler for many vertical scalability solutions I am working on.
If the hoster of a cloud server product or should I better call it a provider is offering libraries for all the major programming languages (e.g., Java, Python) out there that wrap the cloud server API this is a big plus. A plain JSON, SOAP or whatsoever API is fine however wrapping these technologies in code is cumbersome and error-prone. If the hoster or provider does not offer libraries for his API some open-source projects exist that might fill this gap (e.g., JClouds).
So, for me a cloud server needs an API and a library wrapping this API for major programming languages besides many other important cloud computing properties to be a real cloud server.
This text represents my personal opinion and has nothing to do with any company I associated with.
Posted by Thomas King at 09:38 2013-07-26 | Trackbacks (0) | Comments (0)
Does a Minimal Viable Product Need Any Security Considerations? YES! (Cloud Computing)
I really like the lean startup movement. It is result and data driven, and leads quickly to products customers want. One big building block of the lean startup movement is a so-called minimal viable product. The concept of a minimal viable product means that you build a product with a minimal set of features that might not be completely finished and you show this product to your potential customers so that they can give you feedback about it. You use this feedback to improve your product and add the features customers ask for.
If you just started working on your startup and you just finished your minimal viable product please think twice: Did you add security to all the parts of your minimal viable product that work with sensitive customer data?
I consider security a critical component of a minimal viable product that handles sensitive customer data because if you do not have security in mind while building your minimal viable product it might happen that your customers will sue you before you get of the ground. For instance, if you are storing loginnames or passwords of other cloud services or bank account information and this data is lost because you got hacked your customers will turn on you and make sure there is no version one of your product.
I am not saying that you need a multi-layered, very complex security concept already implemented in your minimal viable product. However, I am saying provide basic security measures for the sensitive data of your customers. These first steps already made during the work of the minimal viable product will help you adding more relevant security features while your product grows. And the basic security measures let you manage the security risks you are facing during the early versions of your product.
I am not telling you this story out of the blue. At a startup a friend of mine works it happened that they got hacked a couple of weeks ago. However, because they had added a certain layer of security to their minimal viable product the hacker could not retrieve any sensitive data of customers. So, be aware and think twice of security!
This text represents my personal opinion and has nothing to do with any company I associated with.
Posted by Thomas King at 22:38 2013-07-25 | Trackbacks (0) | Comments (0)
