In-Depth

Architectural Considerations of Modernizing SharePoint Apps

Now that SharePoint is ripe for "app modernization," the next step is to decide which architecture is best to support enterprise requirements in terms of scalability and maintainability.

• By Oliver Wirkus
• 04/24/2017

When enterprises discovered the benefits of integrating business applications into their SharePoint intranets many years ago, they usually built their SharePoint-based business applications as a monolithic block based on Web parts. In other words, the business application was based on a single assembly that included all functionality like business logic and user interface. At that time, most SharePoint-based business applications were built using that approach only because the development environments such as Visual Studio used at the time barely provided any support for different architectures as there was almost no demand for that.

This changed slightly when Web applications started to become popular. Development environments including Visual Studio began to support publishing processes, and frameworks emerged that supported the prerequisites of Web applications. Still, most early Web applications were built as monolithic blocks. However, a few Web applications started to separate the business logic from the user interface and moved it to a different assembly.

Today Microsoft Azure has evolved into a robust platform which allows for developing and hosting business applications in a modern fashion, as explained in my previous article, "SharePoint is Now Ripe for App Modernization." Enterprises that plan to modernize their apps have options in terms of architecture. There are two different approaches, and I will discuss the benefits of each.

First is tying these modern services to the existing business application. App modernization driven by the powerful Azure services is adding additional requirements to business applications. Fortunately, modern development environments (such as Visual Studio 2017) now let developers add those services to existing applications in an unpretentious, but professional manner -- this is calling the concept of monolithic business applications into question.

Usually, Web applications built as monolithic blocks encounter restrictions when it comes to scalability and maintenance. Because they're a monolithic block, these business applications can only be scaled up and down as a whole, even though only one particular function would need (for example) increased CPU power for a short period of time. The same problem applies when it comes to maintenance. Even though only particular functions need to be updated, a monolithic business application needs to be updated and deployed in their entirety.

The other approach is to let enterprises tap the full potential of modernized business applications hosted in Microsoft Azure, in which case they should think not only about app modernization but changing the underlying architecture of their business applications as well. This is where the Azure Service Fabric approach kicks in. In a nutshell, this new approach is focussing on individual microservices rather than monolithic applications. Here is an example: consider a CRM-type application. The following functions can be identified offhand: database handling, user interface handling, business logic, notifications, e-mail and messaging and user handling. The app services approach is focused on services, which means that each function of the fictitious CRM-type application would be built as a separate microservice. As an entity, those microservices make up the business application.

How can separate services each representing a single function make up a complex business application and what are the benefits of that approach? To enable independent services to act as a single business application, it is crucial to enable them to exchange data and messages. In other words, they need to be able to communicate with each other. Microsoft Azure provides Azure Queues and the Azure Service Bus to enable services to exchange messages and small chunks of data very quickly. If services need to transfer more data (like data sets), Microsoft Azure offers Azure tables, Azure DocumentDB or the Azure Redis cache to share data between services.

Although the App Services approach puts additional pressure on business analysts, cloud architects and developers, the two most significant benefits might predominate the extra effort. When it comes to scalability, it is evident that separate services can scale up and down independently. In other words, a large monolithic application doesn't need to be scaled up and down anymore. Instead, just the services which are experiencing a significant change in network traffic or workload are scaled up and down without affecting other services. This granular scaling ensures a nonconstraining user experience and reduces operational costs while increasing performance, whereas scaling of large monolithic business applications often feels stringy and less agile.

The second benefit becomes clear when it comes to updating an existing business application. If a business application is made of single services, each service can be updated separately without affecting other services. This approach not only reduces the cost for development and deployment but also for testing since only the specific functionality of a particular service needs to be tested.

Although the app services approach might only be suitable for large business applications, it makes perfect sense to take this approach into consideration when thinking of modernizing an existing business application. The additional effort of splitting up existing functionality into specific services will be covered by reduced costs for maintenance and improved scalability, which results in a Web application being more responsive and agile -- precisely what we want to achieve with app modernization.