Software as a Service – Never break your sign-up process

Building Azure Costs was and is a long journey implementing a scaling and growing software as a service application. The major goal of all design and architecture decisions is that it scales infinitely. Successful marketing campaigns or great new features may turn the service down. Thanks to the Microsoft Azure platform and their managed platform as a service offerings, it was possible to invent this kind of solution. This blog article series has the intention to give an inside look into this journey and highlights some learnings we had on our way. 

saas

One of the most important and earliest steps to convert a prospect to a user of a payed plan or a free trial is the Sign-Up or Log-In process. When this process is broken customers can’t check out your service and you will lose the option to convert a prospect to a customers. If you think this could never happen that a basic process like Sign-Up can be broken ever, we at Azure Costs experienced another situation. As soon the core processes are not monitored very well, it’s not the question if they will fail, it’s only the question when they fail. Huge platforms like GitHub or Azure as self will recognise that by just watching 15 minutes on the system. If no Sign-Up happens something must be wrong. When you start with a SaaS application your prospect pressure is probably not that high. There are several root causes which needs different counter actions to cover them, bellow some examples are highlighted:  

Your app is supporting external identity provider:
Many SaaS applications also Azure Costs are supporting an integration in external identity providers like Azure Active Directory, Microsoft Accounts or Google Accounts. Even GitHub Accounts are very popular when you more focused on the open source world or when your product become more technically. In an optimal world you would get an error from the identity provider which can be tracked from your APM service like Stackify, NewRelic or Airbrake. But more often we was seeing the situation that the prospect stuck in the inner process of the identity provider. Because of that we invented a system based on BrowserStack to emulate at least one times every hour a couple Log-In and Sign-Up scenarios as it would be done from the prospect as self. This gives us the proof that our authorisation system works as expected.  

Implement:
Automated Login based on web automation tools like BrowserStack or Sauce Labs 

Your business logic throws exceptions because of breaking changes:
In the case your business logic throws exceptions normally your prospect will get an error page which does not show the internals of your application. It’s for sure a bad idea to highlight the stack trace directly at the prospects face. Beside it does not look nice, it is a security risk because an attacker can learn a lot of your service from the stack trace you would expose. Tracking exception means implementing a monitoring and an APM solution. Microsoft is offering a service called Azure Insights which should be reviewed because it comes as part of the Azure Cloud. More powerful services we are using are Stackify and Airbrake. These services ensure that our staff gets a push notification for every single exception in our code. It’s even not expensive because the simplest plans are starting by around 15$ per month. From our perspective, this couple cups of coffee are well invested money to keep your service healthy. Don’t forget covering all your components, especially background worker and WebJobs are often forgotten because an extra mile is necessary.

Implement:
Exception tracking based on APM services like Stackify and Airbrake. 

Your Data-Store has performance limitations:
Another challenge is often that managed services in Microsoft Azure but also in the Amazon Web Services has technical limits. Microsoft describes every limit in this document here. There are two main counter actions to handle this and preventing your prospects for Sign-Up or Log-In. The main counter action has something to do with architecture decisions. When you design your software be aware of these limits and probably invest more in micro services which are using separated storage backends. This would decrease the pressure from a single monolithic data-store. More often modern APM systems are able to monitor performance KPIs of your used data-store and this measurement should trigger alerts when you hit a KPI.

Implement:
Invest in micro services and implement performance KPI monitoring.

When Azure Costs was broken the first time a couple years ago we realised more focus on all of these categories was necessary and since we implemented Exception Tracking for backend, workers and frontend, performance monitoring for our data stores and web automation for external login providers we never lost a prospect in the Sign-Up process anymore.

If you are interested seeing this in action just visit azure-costs.com and try to Sign-Up. We are interested of your personal experience so please use the comment option in this blog to give us more hints in which areas you are investing to increase the service quality of your Software as a Service application.

Advertisements

Hey ISVs, build your own oAuth2 service :-)

Are you a SaaS Software Vendor? Do you have the idea of providing your customers an API first approach? Do you want to offer a scalable solution in the cloud? Why the h… do you need an oAuth2 server?

Many successful SaaS vendors offer an identity infrastructure based on oAuth2. Good examples are Digital Oceans, Microsoft, Amazon or Matrix42 with MyWorkspace. This article intends to explain the reasons why you should offer your own oAuth2 infrastructure when you publish a SaaS application to the world.

Five reasons to offer an oAuth2 service

  • Adapt the Micro-Service-Architecture
    SaaS applications today are different to Web applications 10 years ago. The most vendors are following the micro services architecture pattern. Let’s re-cap what Micro-Services intend to be. At the end this architecture pattern means that a vendor offers many different web services independent from each other for a specific offering. Have a look on the big ones like Microsoft Azure: They offer the Azure Resource Manager, the Storage API or the Office 365 Graph API as independent services. Compared to that public ones, Matrix42 with MyWorkspace offers services for handling identity, files, workflows and BI dashboards. Azure Costs, the service the author is also working on, is divided in separate small services for processing spending information, handling trend analytics or managing teams. All these are good examples for Micro Service and they have something together.jwt
    A session cookie based approach would not work, because this means every web service needs to take care of the session. A token based approach for authorization is a better option and the best option to provide a token is the JWT (LINK to Blog) token.

    How to get the JWT:
    Just use an oAuth2 service you provide for your micro service infrastructure. Check out different offerings in the IDaaS market or write your own.

  • State of the art Single Sign On (SSO) and federated security
    Today customers expect single sign on for their workforce. This means every SaaS application needs to support various flavours of federated security and single sign on. A better approach is to totally rely on JWT tokens and delegate the complex identity work to your oAuth2 service. The oAuth2 service should talk to the different company directories like Active Directory, Azure Active Directory or SAML2. This keeps your micro service infrastructure simple, clean and scalable again and you can drive them with just one concept and not multiple.

    How to connect to other directories:
    There are solutions in the market like Matrix42 MyWorkspace acting as identity bridge. Integrating these solutions reduces the work in your oAuth2 service to mitigate between the different identity providers.

  • Customer requires API First approach
    When talking with customers and the customer likes your solution often the second or third question is “How can I integrate …”. Translated into the language of developers this means “Do you have an API we can easily adapt?”.

    { REST }

    Because of that API first is an approach every SaaS vendor should follow. Remind the first bullet point in this article and assume your API relies totally on JWT tokens. You need to deliver a special JWT token to your customers for integration. Normally this tokens are called app-only tokens and can be used with a client credentials against an oAuth2 service. Azure Costs, as a simple example, explains how to deal with app-only tokens in the this article.

    How to issue customer integration API tokens:
    Provide a separate oAuth2 service that supports the client credentials flow incl. app-only tokens.

  • Support for mobile, web and fat clients required
    Today’s market is not focused on a special operating system or platform anymore. Even Microsoft changed their mind dramatically and now they offer with Azure one of the best cloud platforms for all kind of devices including IOT devices. Mostly every SaaS application has sooner or later the requirement to integrate different clients. The compelling event for this is normally the requirement for a mobile app but also the requirement to support a browser extension or just the integration in an embedded device. oAuth2 delivers different permission grant flows to support any kind of device and use case. This means offering an oAuth2 service gives you the freedom to support any new device because your identity infrastructure is decoupled from your micro services infrastructure.

    How to connect a mobile app to my service:
    Provide a separate oAuth2 service which support, the so called indirect flow. Normally you should not use the code flow but you need to provide some kind of device management.

  • Stay scalable for your access
    Last but not least, scalability or better the option to be ready for growing your company is a key success criteria every SaaS vendor should have an eye on. The micro-service architecture and the decoupled identity infrastructure gives you the freedom the split and combine services on different services in different clouds and in different locations.

    How to stay scalable:
    Decouple identity from resource services and enjoy the freedom to let the infrastructure grow by business needs.

Yes we can! Get your own oAuth2 service

When you think about building an oAuth2 service for your application you can start by building your own stuff. This is a great option when you need to stay under control of everything. There are also IDaaS providers on the market like Matrix42 with MyWorkspace, Auth0 or Azure Active Directory. These providers are a good starting point for your identity management project.

A hybrid approach is often the most practical. This means your engineers will provide a home grown oAuth2 service to support existing user accounts. This service should act as identity proxy to an IDaaS provider to open up the world of federated security and Single Sign On for your enterprise customers. Never waste time and budget on building an infrastructure for federated security by your own.

This article covered many technical topics on a very high level perspective. If you like it, let me know, as I think about creating a series out of it, to cover topics in more technical depth. Feel free to follow this blog to never miss an update about the upcoming series.