Cloud business: Get more, pay less
Today most cloud-agnostic users use the big platforms (read as PaaS) from Google and AWS because it's well known: nobody was ever fired to use them. They are both more or less easy to use.
The engineers there do a good job to provide a mass business, with poor SLAs in every dimension: no guarantees for anything. Today you have to be proud to get your money back if the service is broken (and you as a customer have to prove the outage). And everybody: "YEAH!". Yes, it's like that.
But on the other side, you have to pay a lot of money to enjoy the poor throughput of their cloud storage and the headaches you get when you want to use their network as a network engineer. Do you want to build a simple thing like a router? Maybe you've heard of this rocket science thing (everybody has a device at home for your internet connection). Have fun - not. Controlling traffic is a pain in the ass at Google.
I don't blame the engineers: it's more or less a product management problem.
However, wouldn't it be fantastic to use the infrastructure you like? Because you get the data privacy you like, the throughput you like, the region you like, maybe operated by a company you like? Want to be able to move your data and services just in case?
I make a simple example: a data-driven company that needs a lot of storage, A LOT, and is a Start-Up: how could they pay Google? It's impossible. Could you buy local SSD storage at Google? Yes, sometimes (it's true: new cloud resources aren't always available). But 2 TB for 100 USD per month as local SSD storage?
The classical approach is: you go to some hoster and build everything from scratch on your own, which means hiring a really good DevOps team with at least 3 people. You get empty servers with a pre-installed OS. Have fun - not!
So here is a new deal: choose your hoster, install #aep, based on #kubernetes and #lxc, negotiate(!) a SLA you need(!) and get a fully operated platform with lots of pre-build services like #kubernetes, #cassandra, #postgresql, #mysql, #rabbitmq and start your business within weeks, instead of months and save thousands of USD per month with an unbeaten performance of bare-metal and local SSD storage.
Ok, there are some downsides: because #aep is a container-based platform, deployment times are really short, it's fast as hell compared to virtualized platforms, no overlay network bullshit - you get the real performance.
Ok, there are more downsides: it's reliable. Yes, #kubernetes is a beast when it comes to reliability because there is the primary attitude that everything is stateless (you remember your stateless SQL database?). So they kill/delete infrastructure during operation as a regular thing because they can (I don't know if Obama meant deletion of servers), and there are several cases. To make it short: even if we offer an API through the power of #kubernetes (thanks for that, guys), we made it reliable with the help of #retain (internal development) and #lxc to run a stateful platform - which just works. :-)
So why the heck not everybody is using #aep? Here we come to a problem: we're a tech company (in some romantic fashion), and we don't want to bullshit people. We are good at developing technology but bad at marketing. So if you're going to buy beautiful slides: go to Google or RedHat.
But if you want good technology, reliable, flexible, fast, operated by experts, build with the experience of running real services under high pressure and get phone calls with angry customers WhyTF the service is down: maybe you should give #aep a chance. Want to try? First contact by mail: [email protected]
So what did I do (CEO of #automaticserver) in the past: I worked as a Software and DevOps Engineer on the ground, consulted and operated a lot of big organizations: in Switzerland SRF, Ricardo, Fashiondays, in Germany Metro, Galeria Kaufhof, CrossEngage, Autoscout24, Dailydeal, MediaMarktSaturn.