And the last post in this series … Services! We’ve previously taken a look at the new way we work, the new devices we are using to blend our home and work lives and the new applications that take advantage of these new ways of working. In the previous post we dove headfirst into how users behavior and expectations are changing, and in this final post I’ll take a look at the services that are being consumed by all of the above.
This is a 5 part series.
Modern applications are built to drive a user experience and deliver information to the user. The powerhouses in this world are the services, where the grunt work is done, crunching numbers, working with the data, with the devices focused on providing the mechanism by which the user consumes the information. This new model provides an incredible opportunity for better integration and consistency, with the backend being architected for this in a central way and all updating is done here, which should lead to a more robust experience for the user.
But of course there are some considerations. Things like Identity, Authentication and Management suddenly become more critical, but also potentially more complex. Why did they become more critical? Because you just moved from a model where you control everything to a model where you control very little.
Lets take a look at an example application service. In the simplified diagram below you can see the basic components.
Structure: At the backend you have a set of services running that provide the core of the functionality, they consume storage, network and compute resources. Then you have an identity and authentication model which in the diagram above is leveraging Active Directory and Windows Azure AD (see more below), and the users connecting on a variety of devices to consume the service.
Identity and Authentication: This is perhaps the most interesting challenge. In the old world, back when you were on-premises with physically connected networking and fully managed devices, you could maintain the user identity and authentication using Windows Server Active Directory, and then manage settings and configuration using System Center. But now your app is running as a service in “the cloud”. Now what?
Well, there are a few options here. The best option is to leverage the Windows Azure Active Directory:
By connecting your existing Windows Server AD to Windows Azure AD you can manage a hybrid environment that provides unified authentication and access management for both cloud and on premise services and servers, eliminating the need to maintain new, independent cloud directories
Or if you want to, you could have your users authenticate directly back on-premises but the security implications alone on that one will put a lot of people off!
There are many benefits to applications and services that are built this way, including:
- When hosted on a platform like Windows Azure you have access to almost limitless capacity and only pay for what you consume
- Users can access from any location at which they are internet access
- You control all authentication, identity and access and can revoke at any point in time
- All updates are centrally managed and deployed. The core of the application is running in the back-end, with the user client simply being the consumption mechanism. Yes, you will likely need to push out updates to the user devices, but you have mechanisms like InTune and the app stores across the store vendors to achieve this.
So as you can see, this is a new world, a shift from the traditional server-client model into one that is genuinely service orientated, providing users with an easy consumption method.
I hope you enjoyed this series, and as always any thoughts. comments or feedback is always welcome