Share →
Buffer

Cartoon-061715-Azure-Architecting-2

Part 1: Why Create a Platform-as-a-Service (PaaS) Solution?
Part 2: Storage Options with PaaS
Part 3: PaaS Architecting: Designing Apps for the Cloud
Part 4: PaaS Security (coming soon)

Article by Colin Dembovsky

Platform as a Service (PaaS) has some incredible benefits – no worries about OS updates, quick and easy scale out (as and when you need it), and pay-as-you-use billing. However, if you’re going to build for the cloud – or move your current application to the cloud – you’re going to have to make sure your application is “cloud ready”.

Moving to PaaS means that your application must be designed for scale out, as opposed to scale up. Scale out means adding additional servers to run your application on, rather than scaling up, which means beefing up a single server. Besides challenges like state data (which now can’t be stored in memory on any single server) there are other aspects of the application that you need to consider: data storage, security, monitoring and configuration. You’ll also need to consider splitting large applications into smaller, independent subsystems – which will impact how you work, source control, builds, deployment and testing. Cloud enablement is something you’ll need to do consciously if you’re going to succeed.

State Data

In-memory stores are clearly out, since you application can (and should) be spread over multiple servers. So where do you then store state data? Fortunately there are several mechanisms your application can use.

If your state data lives beyond a session, then you’ll need some sort of permanent store. Both relational and table storage options work well for this case. If your state data is complicated, has a deep hierarchy of objects or requires stored procedures to manipulate, then relational databases are a good option for you. Table storage is a good option when your state data is simple, can easily be denormalized and requires no stored procedures to manipulate. (The next section discusses these a little more.)

If your state data doesn’t need to live beyond a session, or you require very low latency, high-throughput capabilities, then consider “cloud caching”, such as Azure Redis Cache. Redis Cache is a key-value store with atomicity, synchronization and other features.

Application Data

Most applications require some sort of data storage. If you’re moving the website into the Cloud, you’re going to have to consider how to move your data there too!

Relational Data

Already using SQL Server? Then migrating to Azure SQL Database could be a quick solution to getting your database onto PaaS. Be aware that you’ll need to consider SSRS, SSIS and SSAS carefully if you use these additional services – they aren’t available in PaaS, so you’ll need your own infrastructure (or at least a Cloud Virtual Machine) to host these services – though they’ll have to be able to connect to the Azure SQL Database.

Table Storage

If you have structured data that does not require complex joins, foreign keys or stored procedures, you may want to consider Azure Table Storage. Table storage allows you to store terabytes of structured data that is highly scalable.

Blob Storage

What if you have large amounts of binary data, such as videos, images, documents or other files? Perhaps your “non-cloud” application was getting these from a file share. You’re going to have to consider how to store these blobs for your cloud-enabled application. Consider a service such as Azure Blob Storage.

Security

How are you authenticating and authorizing your users? Moving to PaaS means you’ll have to think about this in a new way. If you’re already using a 3rd party solution (such as OAuth) you have to make sure they’ll work from the PaaS provider.

Active Directory (AD)

PaaS application cannot authenticate directly against your corporate AD. You can set up an Azure Active Directory (AAD) that can sync to your on-premises AD or use a secure token service (such as AD FS) to provide authentication against your on-premises AD. If you’re considering migrating to AAD, bear in mind that it has a static set of claim types that are not customizable, so make sure that you can authorize against the built-in claims.

Monitoring

Since you’re not going to have control over the infrastructure your application is going to run on, you’ll have to rely on your PaaS provider’s monitoring tools. Fortunately Azure provides Windows Azure Diagnostics (WAD), allowing you to access diagnostic data for debugging as well as performance monitoring, resource usage, traffic analysis, capacity planning and auditing. You can also consider adding Application Insights to your application for enabling custom metrics, dashboards and notifications.

Automated Builds, Deployment and Configuration

Hopefully you’re not hard-coding connection strings or any other configuration settings in your application. Moving to PaaS means that you’ve got the ability to deploy to test environments (that you can tear down once testing is complete) so you’ll need to make sure you can automate deployment of your application. Automated deployments remove “fat finger” errors and allow you to quickly deploy applications to new environments – but that does mean you’ll probably need to tokenize your configurations somehow to facilitate deployment across multiple environments. Automated deployments also require automated builds – you’ll want to make sure you can build a single package that can be deployed consistently across numerous environments. Consider tooling such as Release Management for Visual Studio to help you track your releases.

Application Specific Considerations

Of course every application has a unique architecture. You’ll have to consider good design practices such as separation of concerns – perhaps instead of a single large web application, you can split your application into a service component and a frontend component. Splitting your application into smaller “micro services” allows you to scale components independently – perhaps the frontend isn’t used as much as the service layer – so you can scale out the service layer more than the frontend, driving increased scalability at lower cost. Be aware that this decision can impact how you structure your source control, automated builds, deployment and testing procedures.

Conclusion

Architecting applications for PaaS takes careful consideration – from thinking about where and how state and application data are stored, how authentication and authorization will work, how to monitor applications, how to deploy and how to re-compose large applications into smaller decoupled services. However, the benefits of PaaS make these considerations worthwhile, allowing easy and massive scale out as and when you need it. We briefly looked at some cloud-enabling mechanisms for these areas, providing you with some alternatives to think about as you design for the cloud.

Print Friendly
Tagged with →