Tips for Architecting Successful Solutions & Systems, Part 2: Cloud Considerations

Welcome back. In Part One of this series, I covered a few of the base principles that are part of architecting a software solution. This includes getting clear functional and non-functional requirements; stating assumptions; and recognizing and evaluating trade-off considerations, including return on investment (ROI).

In Part Two, we will look at cloud considerations and discuss how they drastically change the rules when it comes to architecting your solution. Even if your organization doesn’t plan to transition to the cloud right now, the possibility is highly likely to come up in the future. Both private and public cloud migrations are accelerating at a rapid pace. If you’re only thinking about on-premises, be careful as this can make a future transition to the cloud much more difficult.

Not all cloud service offerings are created equal, and the type of offering – whether Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS) – will influence architectural choices you need to make. With a service model that provides IaaS hosting, you’ll find that that the cloud impacts your solution the most, whereas a SaaS model has the least impact. The primary reasons for this involve the number of layers that you have direct control over. The easiest way to visualize this is to review the technology stack involved in each as shown in the figure below:

With IaaS – the most common examples of which are Azure VM or Amazon Web Services EC2 – you still have control over the most layers, as shown in the diagram above. With SaaS models – such as Salesforce CRM and Office 365 – you have control over the least number of layers. In other words, the more layers you manage, the more considerations you need to keep in mind. As a software architect, it’s not normally up to you to decide which of these three models your application will use. This choice is often made at an executive level by either the CTO or CIO. Your job is to architect the solution based on the model that’s provided. Let’s walk through a couple of example scenarios – one simple and one more complex.

Example 1 (simple)

As a consultant, your customer needs you to develop a custom application. Your customer’s strategy next year is to transition much of their on-premises data center to EC2 (virtual machine) nodes within Amazon Web Services (AWS) to reduce the overall costs of managing a data center. AWS EC2 is an IaaS hosting model – meaning that after the data center transition is complete, your application will not have direct control over any of the hardware (servers, storage, networking) or virtualization hypervisor. Thus, you would probably want to stay away from design choices that depend on low-level networking specifics (such as IPv6) or expect a certain brand of hardware (such as utilizing special APIs that the storage layer provides).

Example 2 (more complex)

Let’s say that you need to develop a custom application that will run within SharePoint Online, part of Office 365 that uses the SaaS model. Perhaps the custom app will help you manage meetings, like the AvePoint’s Meetings app. If you’re not that familiar with Office 365, you might assume that you can’t really do much since in a SaaS model you only have control over the data. This is mostly true, but Office 365 apps can run outside of the Microsoft SaaS hosting model, and these apps call into Office 365 through a set of published APIs.

A very common example includes SharePoint-hosted add-ins where the API is using the Client Side Object Model (CSOM). In this model, the application runs outside the direct hosting engine within SharePoint Online, and the app could be hosted on-premises or in another cloud provider that uses a different hosting model (such as IaaS or PaaS). One common cloud model for these types of apps is Azure Web Apps, which uses a model that resembles PaaS. I say “resembles” because, with Azure Web Apps, you have some control over the runtime. For example, it could be based on .NET or another provider such as PHP or Java. The figure below gives you a glimpse of how this architectural pattern works.

This scenario becomes much more challenging when you need to factor in other cloud-specific considerations such as:

• Security, which includes authentication, authorization, even data sovereignty (meaning whether the data must be hosted within the country of origin)
• Backup and restore
• Maintaining a hybrid-compatible posture, which could involve part of the app running in the cloud and part running on premises, or it could involve the app calling into infrastructure or other dependencies somewhere else

As you can see, architecting for the cloud does add complexity! I like to think of it as a factor that gives you more options, but having too many options makes any task or decision that much harder.

As a final takeaway, know that to effectively architect for the cloud, you must do your homework on the particulars of the hosting platform. You may also need to involve other constituents in this decision. For example, you may need to involve security and privacy officers or the CTO in order to better understand the organization’s overall cloud roadmap. Keep in mind that you don’t need to be an expert across all aspects of a cloud implementation. You should plan to rely on a community of internal and external experts for input or to validate your design choices. If nothing else, getting a second opinion could be the difference between success or failure. I’ll talk more about this in our next post.

What’s Next?

In our next installment, I’m going to get into tips for success. I’ll give you some suggestions on researching other patterns and practices, architecting in layers, and when you can get away with taking short cuts. In the meantime, if you have a question about architecting solutions, please leave a comment on this post! I’d be glad to answer and discuss any challenges you’re currently facing.

To learn more about how AvePoint can help you meet your specific business requirements with custom solutions, visit our website today.