BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Most enterprises that depend on Microsoft's Windows Server and .NET software already know that it's pretty easy...
to create hybrid clouds using Microsoft's Windows-centric PaaS service, Azure. Some want, or need, to extend hybridization of .NET beyond Azure. To assess all your .NET cloud development choices, recognize specific models of .NET hybrid cloud. Take a cloud-centric approach to review these models, and pick an approach that's most harmonious, but not necessarily the best.
The key question for a .NET hybrid cloud planner to address is what's your .NET commitment? Is it to hybridize .NET across multiple cloud providers or to hybridize applications written both with and without .NET support. If you want to use .NET in all your applications and want broader cloud choice, then your focus should be on IaaS hosting of .NET components. If you don't want to use .NET, then you should look at options for .NET-independent component integration.
Azure is a PaaS, which means that Microsoft middleware is a resident in the Azure cloud. If you don't want to use Azure for public cloud hosting, you could either build Windows .NET machine images of your own (be sure not to violate software licensing requirements) or acquire the necessary Microsoft licenses from your cloud provider (Amazon offers this, for example).
The biggest complication in IaaS hosting .NET components, reported by users, is that of addressing. Some of the older versions of Microsoft server components may not be fully compatible with the addresses assigned by public cloud providers. This problem is less likely to arise if you run the latest versions of Windows software. So before you undertake a .NET hybrid cloud strategy you may want to upgrade everything to its latest version.
Planning your .NET cloud development
If you plan on building hybrid applications that are not entirely based on .NET, then you should decide the role of .NET. Then insure that role is fully supported in all your development and deployment. In general, there are two options. One is to enforce .NET middleware use on all development, including Java, by compiling applications with proper middleware components. The other is to adopt a component integration strategy, such as microservices, that will allow hybridization of applications based on any middleware model.
Most businesses feel that using .NET-compatible middleware with Java or other non-Microsoft development frameworks should focus on calling .NET functions rather than relying on implementations of .NET features in third-party packages. Thus, the two .NET hybridization options reduces to just how you interface, directly with .NET components or with a higher-level microservices. If you're focused on developing with .NET for a long term, you could standardize on using .NET components. If not, consider moving to microservices or other component interfaces to create your hybrid clouds. There are good reasons for doing that even if you are totally committed to .NET.
Broad trends in cloud evolution favor microservices over explicit use of .NET interfaces. The reason is that things like horizontal scaling, failover, and even cloud addressing are easier if you have very loose coupling among components. Microsoft may enforce web-service models for some of their interfaces, and this may be harder to integrate. On the other hand, if your applications are all designed with component integration based on a simple REST/JSON interface model, you can take advantage of all cloud features, and still develop each component/microservice either using .NET or without it. The choice won't impact your cloud deployment.
All of these show that it's best to think of .NET hybrid cloud options starting with your cloud goals, and not with your .NET goals. If you plan aggressive public cloud use for failover and cloud bursting, then the components of your applications that would be involved should be reviewed for implementation as independent services, and in particular as microservices. It insures that you can scale and replace components easily, and that cloud and private WAN addressing harmony is achieved.
Many .NET applications are distributable. But scalability depends in most cases on a combination of load balancing among multiple component instances and on stateless component/service behavior. Since .NET cloud development often follows the original SOA/web service model, it does not enforce stateless behavior, which means redoing the components for stateless operation. If that's not possible, then it's smart to retain Azure public cloud services until it is.
It may also be necessary to harmonize those original SOA/web service goals with your hybrid cloud goals. One of the explicit goals of SOA was to facilitate component reuse across application boundaries through the use of enterprise directory and discovery processes. In practice, many businesses didn't find dynamic reuse of components as useful as expected. Since microservices don't provide this explicit support for discovery, you may want to consider either a general application delivery tool (such as NGINX) or adopt a client-side or server-side microservice discovery design pattern [we can reference the microservices and SOA piece here for more detail].
Making .NET cloud development work
The final, but far from least important point is harmony. Your .NET strategy has to harmonize with your cloud and hybrid strategy. You can't take steps for hybrid clouds that will have a negative impact on other plans to exploit and expand your .NET cloud development commitment. You also can't expect to rely on .NET in the cloud while phasing it out in a data center. The cloud is an instrument of IT policy, not the foundation of it.
Making things harmonious means broad engagement. Enterprise architects, software architects, developers and development managers, and operations planners and managers, all need to be involved in any hybrid and .NET decision to be sure that all the implications are clear. Microsoft's plan for hybrid cloud is obviously centered on Azure, and a decision to take another path puts more pressure on your own managers and planners to make sure that decision is the right one.
Learn about hybrid cloud integrations and workflows
Know where Azure stands in the race against AWS
Know more about different cloud providers
Learn how to prevent hybrid app security