PaaSyfying your web apps in Azure – An exciting time for developers
A bit of history…
Windows as a platform currently supports various business applications, however it has taken a long time to evolve to a model where developers can deploy their applications reliably.
From its roots as a desktop operating system, Windows Server has struggled to support simultaneous business applications. This was further compounded by the early noughties trend to consolidate servers. Microsoft thus responded with containerized technologies (SxS components, virtual registry, .Net…) to isolate application components, but this only addressed some of the issues.
Next came virtualization with the promise of on-demand infrastructure. Whilst it addressed the issue of sharing it still required a lot of post provisioning configuration. This lead to long wait times and very few organisations managed to deliver true self-service platforms to their developers. In the end, developers still had to deal with infrastructure and its configuration when all they wanted was a host on which to deploy application code.
Then came the early days of Cloud, this was focused on self-service delivery of infrastructure (IaaS). While it solved the problem of developers gaining access to resources, they were still having to configure the infrastructure before deploying their code.
More recently came PaaS (Platform as a Service) – one of the first implementations of this was the Google App Engine. Through sheer excitement RedPixie then created proof of concept projects and client engagements using Python and Java. We were really excited about this as a development environment and realised that this was the future of business application development. However, GAE didn’t provide any mechanism for hosting .Net code and there were restrictions with Java library support which meant applications needed to be designed to run on it.
Windows Apps and PaaS….
As a developer, Azure PaaS is a great proposition. With true PaaS we have eradicated long wait times for infrastructure, followed by lots of pre-configuration before installing my application. Azure PaaS isn’t just for .Net apps either, supporting Node.js, PHP, Python and Java as predefined technologies.
The platform provides me with mechanisms to handle security, logging, configuration, dynamically scaling and monitoring. My application is completely isolated from other processes contending for CPU and other resources.
PaaS is the ultimate self-service infrastructure solution, alleviating the burden of provisioning and managing infrastructure in exchange for a managed platform. This provides a consistent and stable host for my application.
At RedPixie a large number of our clients are in the process of migrating or at least experimenting with hosting their internal application in Microsoft Azure and we expect that to explode over the coming year.
This is indeed an exciting time for application developers particularly those working in organisations building and maintaining web applications that require frequent updates. The Microsoft tools are no longer just point and click the Azure PaaS tooling is totally scriptable and is designed to be incorporated into your continual delivery processes.
Microsoft have always had the ability to confuse developers with their product naming and Azure is no exception. Services and technologies such as App Services, Web Apps, Web Roles and Cloud Services it is easy to get lost in a myriad of names that appear to have different names for the same component.
However, Microsoft has tried to consolidate this and broadly speaking for bespoke application development there are three options:
Web, Mobile, Logic, Apps
Web and Worker Roles
Windows, Linux VMs….
As you go down the list flexibility increases at the expense of deployment ease. Microsoft is keen to encourage application developers to utilize App Services before resorting to the other methods.
Web Apps are Microsoft’s pure PaaS option. Whilst under the covers you are ultimately using a virtual machine hosting a Web Server the solution is far more than just a container. The environment hosts an open source software product called Kudu.
Kudu is an impressive tool which makes the management of your application a lot easier. Providing access to logs and tools and either Powershell or command line access, it teases you into thinking you are on a Windows VM. Its only when you try violate the web app environment’s integrity that it reminds you that you are in a restricted sandbox.
One of the interesting features for .Net apps is that Kudu will compile and deploy your application directly if supplied with source code. This feature can also be used to trigger an application recompile and deployment when the code is checked into a Git repository.
Another related feature to this is the “Deploy to Azure” button. This is an innovative idea that allows others to deploy your application into their Azure subscription. Which could have applications for demo products or SaaS solutions. The concept is that users of your application can click a button on a web page that links a GitHub. Not only can a web app be deployed but an entire application stack can be created via a JSON file (aka. ARM template). These templates are quite complex to manually author but I expect the process to improve over time with the advent of new tooling.
Whilst all these evolving cloud technologies are changing the way software applications are hosted and delivered, if your company is reluctant to host in the cloud they don’t help much. That’s where the forthcoming Azure Stack fits in. Azure stack is essentially an on-premise Azure cloud with all the same features as the public version. This really will affect internal business application development allowing easy access to legacy services as well as email and directory services whilst providing all the benefits enjoyed by using Azure services.
At RedPixie we believe that Azure Stack will have a profound effect on the way companies deliver their internal applications and developers will finally have a self-service platform that allows them to concentrate on delivering continual business value.
Written by Paul Greer | Principal Devops Architect, RedPixie | See his LinkedIn Profile