First Look at Platform.sh - a Development and Deployment SaaS

[ChrisChinchilla]

Originally published at: http://www.sitepoint.com/first-look-platform-sh-development-deployment-saas/

Not so long ago, many of us were satisfied handling deployment of our projects by uploading files via FTP to a web server. I was doing it myself until relatively recently and still do on occasion (don’t tell anyone!). At some point in the past few years, demand for the services and features offered by web applications rose, team sizes grew and rapid iteration became the norm. The old methods for deploying became unstable, unreliable and (generally) untrusted.

So was born a new wave of tools, services and workflows designed to simplify the process of deploying complex web applications, along with a plethora of accompanying commercial services. Generally, they offer an integrated toolset for version control, hosting, performance and security at a competitive price.

Platform.sh is a newer player on the market, built by the team at Commerce Guys, who are better known for their Drupal eCommerce solutions. Initially, the service only supported Drupal based hosting and deployment, but it has rapidly added support for Symfony, WordPress, Zend and ‘pure’ PHP, with node.js, Python and Ruby coming soon.

It follows the microservice architecture concept and offers an increasing amount of server, performance and profiling options to add and remove from your application stack with ease.

I tend to find these services make far more sense with a simple example. I will use a Drupal platform as it’s what I’m most familiar with.

Platform.sh has a couple of requirements that vary for each platform. In Drupal’s case they are:

• An id_rsa public/private key pair
• Git
• Composer
• The Platform.sh CLI
• Drush

I won’t cover installing these here; more details can be found in the Platform.sh documentation section.

I had a couple of test platforms created for me by the Platform.sh team, and for the sake of this example, we can treat these as my workplace adding me to some new projects I need to work on. I can see these listed by issuing the platform project:list command inside my preferred working directory.

Continue reading this article on SitePoint

[s_molinari]

Thanks Chris for the very interesting article and thanks Site Point for publishing it.

I find the service very interesting personally. I’d just like to point out what I consider kinks in the armour from a customer’s business perspective.

The pricing structure starts off with a licensing cost structure and that goes a bit against the principles of the “pay for what you actually use” construct of cloud computing, which PaaS is a part of. Yes, for the platform and the work that goes into it, there should be a price and $10 per person per month is relatively fair.

However, the usage of the platform, should have much more clear pricing. How much is the database usage? How much is the application node usage? How much for bandwidth? etc. If this is all based on a environment price, then the customer is often paying for something they aren’t getting and over the years, this simply works against the customer. (they might as well own their own server stack). This kind of pricing is the old “rake’em over the coals” attitude of enterprise business, which companies like Oracle have been known to take clear advantage of. So, I have to ask, who are their real customers? Their pricing, at first glance, seems reasonable, but there are other costs involved. These are sort of explained in one line (the smallest) on their pricing page and there is no way, this can be “all of it”.

As for the services offered. It is interesting they went with MariaDB. They say “massively scalable”. Well, MariaDB isn’t massively scalable. If they had said they offer MySql Cluster, I might have considered that somewhat massively scalable. But, that is questionable too. So, as a user I’d actually be worried about scalability and how they handle it.

But then they might say, well, we do have Solr and Redis and these are massively scalable. Then I would counter, uh. Nope. Redis is still far from massively scalable. It is still a single thread single process system, which means multicore architecture isn’t even taken advantage of. There is Redis Cluster and if they were to say that is what they offer, then I might agree with massive scalability with Redis. But, there is no mention of it being used.

Solr is another story. It was built for horizontal scalability, like most NoSQL databases. But then, it is only a datastore to support a powerful search engine and not really a datastore for data persistence. So, from a database perspective, I am covered on search for scalability, but not really for the core database. And, what interests me most is, in general for a platform, the database costs are some of the highest of any services offered, yet there is no mention of extra costs for a growing database. From my experience, a GB of database storage in a PaaS like service should be around $20-$40 per GB. Yet, there is no mention of database costs at all.

From a pricing standpoint, I am just not certain what is going on. I can have 10 developers, working on multiple dev environments. Ok. From what I understand, that would be 10 x 10 = $1000 per month. That is considerably cheaper than needing server admins in my team to keep up infrastructure. But now I want to go to production. Now I must pay for a production environment. Ok. The basic one is $50 per month.But the largest environment is 7GB. Not exactly killing it on power. What kind of compute power is behind that 7GB too? And 7GB of what kind of memory?

Again, from a business perspective, my costs as a customer aren’t clearly provided. Just as an example of cost transparency done right, check out Heroku. https://www.heroku.com/pricing At first you might say, Heruko is a lot less transparent, because there are so many things to account for. But actually, they are a lot more transparent, just like any PaaS should be.

My intention is not to hack on Platform.sh, but to try and demonstrate missing clarity in their pricing structures. As a supporter of PaaS, I really hope Platform.sh can come through and be more transparent. I think they need to think a bit more about their license and environment cost structures and depict their prices better accordingly, so there are no surprises on both sides.

Scott

[yannski]

Hi @s_molinari regarding pricing, what do you think about https://scalingo.com/pricing ? (disclaimer: I’m the CEO).

[swader]

@s_molinari

My intention is not to hack on Platform.sh, but to try and demonstrate missing clarity in their pricing structures.

Many thanks for this really thorough feedback - you really hit the spot on most issues one might complain about when considering them.

[s_molinari]

Looks pretty transparent. The only open question in my mind over the offering is, what kind of bandwidth is available and what will an overage on bandwidth cost me?

I am also not in favor of “included” things, like your database service always “includes” some amount of storage. Most database as a service (DBaaS) offerings simply have a base storage price per GB, whereas I even believe this could be broken down into MB and thus, I as a customer, won’t be paying for memory or capacity I don’t need or use. The basis of a database service should be for the storage only and what it takes to “serve up” that storage. This pushes the provider to be more cost and performance effective, because there is no overprovisioning. It also means the overall price is actually more expensive, but then I can, as the customer, be guaranteed I will have decent performance at all times. And the costs are completely relative to my usage of the system.

My point is this. Anything being part of cloud computing should be as close in costs to actual usage as possible for it to be the most effective and cost efficient, on both sides. Cloud Computing lets us do that and any service built on that premise should also stick to it too as much as possible.

Scott

[robertDouglass]

Scott, thanks for the feedback. As the platform.sh product manager, I’m really really happy to hear it. The pricing structure is our first shot at getting pricing right. It’s tough business, and we’ll iterate on it, incorporating feedback from yourself and others.

Regarding the developer licenses: we’re considering getting rid of them in the near future. Also, we’re intending to move to “per-service, pay what you use” pricing as soon as we can engineer the the supporting bits around that. I think these two changes will address your pricing concerns pretty squarely.

When we scale MySQL (MariaDB), we do so using Galera Cluster. It works quite nicely, and allows us to take your database from a few CPUs and GB or RAM to nearly 100 CPUs and 180 GB of RAM without ever taking your application offline. This is available to our Enterprise customers.

Solr is scaled using SolrCloud. Redis is not scalable, as you say, but we provide high-availability Redis so that if one instance fails, another takes over (the cache data is assumed to be ephemeral and will be rebuilt).

Hope that answers some of your questions!

Cheers,

Robert Douglass

[s_molinari]

Thanks Robert. Your answers are good ones. I appreciate the response too.

I don’t really have a problem personally with the licensing, as long as that is the cost I am paying for the work put into the platform and the overall service and those costs are also not taken into account in the infrastructure. For instance, you might need the licenses, simply in order to control access. Your licenses are reasonably priced too, thus not a KO criteria IMHO. And then again, if you have a user access system, but don’t really care about how many users are on the system or rather you know the number of added users won’t be excessive in any damaging way, then the licensing might not be necessary and the costs for the platform’s development and maintenance can be spread across the infrastructure services.

Galera Cluster isn’t too bad. I consider MySql Cluster the better solution currently though. What makes it unattractive is Oracle luking behind it. LOL!

What intrigues me is why don’t you support MongoDB? The PHP driver is pretty good and the new driver PHongo is going to be pretty cool too, especially if their vision of PHP developer driven extensions comes together well. I hope it does. But certainly, if your goal is to provide Node.js support later on, then offering MongoDB support with it is a no-brainer.

Scott

[robertDouglass]

Scott - we actually support MongoDB. It’s not advertised anywhere as it’s in the “invisible beta” stage, but it’s deployed. If you wish to use it, a support ticket will get you the needed information. Same with Elasticsearch and PostgreSQL. As soon as we’ve put them through their paces, we’ll release documentation on these services.