In today’s guest post, Rainer Stropek, co-founder of software architects, gives us some insights on how to evaluate PaaS solutions in order to find the best one for your product.
At the moment, we are working on a SaaS project in which IoT (Internet of Things) plays an important part. While reviewing my work from the past weeks I was surprised to see how my work as a software architect has changed since we made the move to Platform-as-a-Service (PaaS).
In this article, I’d like to provide you with a guide on how to evaluate other PaaS services.
The Past of Software Development
Decades ago, software development for me meant primarily figuring out algorithms and optimizing them because of resource constraints.
Over time, class libraries became more and more powerful. The open-source movement and the web brought a myriad of ready-made components and frameworks.
They reduced the need for inventing new algorithms to those parts of a software product that is really unique. For anything else (e.g. UI components, cross-cutting concerns) you can always find an existing, decent library.
At least in my domain of work, software architecture became increasingly important compared to figuring out complex algorithms.
Nowadays, my job has changed again.
Finding libraries and frameworks is still important but another question has become determining: Is there a PaaS service for my problem?
What Does PaaS Really Mean?
PaaS allows us to focus on the core added value that our products provide. We can invest more time into what makes them special instead of dealing with commodity topics.
Specifically, PaaS means for us…
- …no setting up and maintaining servers
- …somebody else makes sure the services are up and running
- …we get SLAs (ideally financially backed)
- …somebody cares for updating the service without us having to do anything
- …cost savings because the service provider benefits from scaling effects
Sounds great, right? So where are the drawbacks of using PaaS solutions?
Using PaaS is also a great commitment.
If the PaaS service goes down, our own service is usually negatively influenced. In the worst case, it can mean a downtime for our users.
If you embed a component in your software and run it yourself, you can act if something bad happens.
With PaaS solutions, you have to trust the service provider that they fix the issue fast. Therefore, it is crucial to carefully evaluate services before betting your business on them.
How to Find PaaS Solutions?
The cloud is full of great services and it is really hard to keep up to date. My most important strategies for that:
- Spend time reading news sites, newsletters of major PaaS providers, follow great bloggers, etc. BTW – I love feedly for that.
- Visit industry conferences
- Participate in user group meetings and other community events
You can get valuable knowledge from them but you also have to share your own insights. Start a blog, share code on GitHub, speak at community events, host user group meeting – it’s fun and makes sense.
2. Does The Solution Offer Everything We Need?
Once discovered, we have to find out whether the service offers what we need. Though this one seems obvious and simple, it often isn’t.
- Quality of documentation isn’t always perfect (e.g. incomplete, covering just basic use cases, outdated). You have to invest time and money building prototypes to evaluate the offered functionality.
- If some details are missing, you have to study roadmaps or even get in direct contact with the service provider. Do they plan to develop the missing features? Did they already publicly commit to delivering them? Credible ETA available?
- Does the service offer extensibility mechanisms so that we can add the missing features on our own?
- Can/should we adapt our requirements so that the PaaS offering becomes usable? Is the advantage of using a ready-made service big enough to justify a tradeoff?
Never decide about using a PaaS offering based on marketing material or the website. Study the documentation closely or – even better – verify your assumptions with prototypes.
Tip: Many PaaS providers publicly discuss requests for new features on platforms like Microsoft Azure Feedback), in GitHub issues (e.g. Telerik Kendo UI) or simply have a feedback tool like Usersnap in place. Use those channels and engage in conversations there.
3. How to Trust The PaaS Solution?
Using a 3rd party PaaS offering is different to using an external component. You do not only depend on the supplier’s ability to write great code. You also rely on their skills regarding running a secure and reliable service. Here are the indicators that influence my trust in service providers:
- Does the company have a successful track record providing PaaS offerings?
Do they “dogfood” (i.e. use the service for their own business like Microsoft using DocumentDB for millions of users of OneNote)?
- How active is the community around services of the provider (e.g. on Twitter, Facebook, user groups, blogs, etc)?
- What’s the company size and financial situation?
- Do I personally know people that I trust who work there or who have been using the service successfully?
- Does the provider communicate openly (e.g. blogs, participate in open source projects, public issue management, public feedback portals, white paper with behind-the-scenes information, etc.)?
- Does the provider have external certifications (e.g. ISO)?
- Does the provider make it easy to start business (e.g. no up-front, long-term commitment necessary, free or nearly free pricing tiers for getting started, etc.) and easy to stop it (e.g. self-service data export features)?
4. Where Is The Service Offered?
Location matters. Especially in Europe, regional aspects matter even more. You should ask yourself the following questions.
- Does the provider offer the service in European data centers?
- Does the provider at least care for Europe (e.g. publish information about European data protection conformity) or do they just focus on other parts of the world?
- Does the provider offer services in the same data centers that you are in (e.g. at mLab, you can select the public cloud – Azure, AWS, Google – you want them to host a MongoDB for you)? That might be important for security and performance reasons.
- Are your terms of service regarding the location of data storage, data processing, support, etc. compatible with the terms of the provider?
Tip: This is not only a technical matter. You might need to ask your lawyers on this point.
5. Does The PaaS Pricing Work For Our Business?
Building a sustainable business model for SaaS in the cloud is all about keeping your costs per subscription under control.
Finally, you have to earn more money per subscription then you spend for development, running and distributing your cloud-based SaaS app.
Evaluate the price of the PaaS offering you consider by checking whether it is compatible with your pricing and business model.
Here are some questions you should ask yourself:
- If your customer base grows, does the costs of the service grow faster than your revenue?
- Does the costs per subscription eat up too much of your margin per subscription?
- Can you get long-term fixed prices (consider exchange rate risks, too) that are compatible with the pricing terms you offer your customers?
6. Is The PaaS Solution Built on Industry Standards?
Every PaaS offering comes with a certain lock-in effect.
You should ask yourself how difficult it would be to move away from the service.
Don’t get me wrong: I am not saying that you have to avoid lock-in by all means. If the service you select works perfectly fine, it will be of great benefit for your business.
However, being prepared for the unexpected is never bad. What if the provider or the service goes out of business? Globally acting service providers in the cloud are likely to not go away from one day to the other. Yet, large companies sometimes stop PaaS offerings because e.g. they don’t make enough money from it.
Industry standards can help. They make it easier to switch.
Let me give you an example.
Azure DocumentDB databases can be used as the data store for apps written for MongoDB. If this service would be stopped (I definitely do not expect that to happen anytime soon), you could switch to another MongoDB PaaS offering.
7. Is There A Need For Special Agreements And SLAs?
If you have to sign service level agreements (SLAs) with your customers, you might want SLAs from the PaaS offerings you use internally, too.
Just like with the costs issue, it is a question of compatibility. Will you get enough compensation from a service provider if their failure led to you having to pay your customers a fine for a downtime?
Financially backed SLAs from PaaS providers are not only a kind of reinsurance. They have other advantages, too.
Here is an example.
SLAs from underlying cloud services are great for your marketing brochures. “Our service runs on database clusters with an SLA of 99.95%”, this probably sounds good for your customers.
There are a lot of benefits when choosing the right PaaS solution for you and your business. Finding the right one, and making sure that the chosen solution offers everything which is needed for your business is a key success factor in the long run.
Do you agree to my checklist? Do you have additional evaluation criteria? I would love to hear your feedback in the comment section below.
About the author:
Rainer Stropek is co-founder and CEO of the company software architects and has been serving this role since 2008. Rainer and his team are developing the award-winning SaaS time tracking solution “time cockpit”. Previously, Rainer founded and led two IT consulting firms that worked in the area of developing software solution based on the Microsoft technology stack.