Host Platforms

When I design a solution, I always ask myself, “Where am I going to host this solution?” This question helps me understand several areas² of the production to design and develop. It helps in planning whether the solution will be an N-tier, microservice, cloud-native, or serverless model. The cloud platforms make it easier for developers to publish their solutions to the customers with a single click. Vendors also make it simple for developers to lift-and-shift their products to make them cloud-native.

Modern solutions must fight a never-ending fight of using/not using Docker for their deployments. Regardless to say, whether you use Docker or not, your infrastructure can be automated. To keep things simple, I will introduce most of the concepts using Docker and also mention some direct³ deployment models.

Docker and Containers

Docker tends to provide some useful ways to automate deployments, such as by using web hooks. This helps with an automation pipeline. You develop your code on your own machine, then send it to be built on a CI server. The CI server uploads the built Docker images to a Docker Hub. As shown in Figure 6-1, your Docker Hub triggers a web hook on the hosting platform. Then your images are pulled, and your apps are updated on the hosting platform during this flow. This happens automatically. This happens in (around) three different environments, but they are linked together with triggers and web hooks.⁴

Three separate environments control the automation job for your latest updates on the production environment. Apart from the security of these environments and their respective commands or parameters, you also need to configure their automation stability. You are responsible for migrating any legacy code or script. You must always be ready for change.

This example⁵ uses my Docker image and replicates it to three instances. Each instance receives a resource of 10% CPU and 100MB of RAM. From an IaC standpoint, this is excellent. You can review how your infrastructure is being used. Your applications request the resources and you allocate a top limit to them. Each time your application shows poor performance, you can review the IaC and apply any necessary changes. GitOps can then help you keep the changes in history and audit them in the future.

Network Security

I mentioned previously that you should perform your QA and other tests (DAST, RASP, etc.) on the production environment. This will give you a better idea about your software and how customers are using it. This is also critical because you cannot perform QA operations directly on a production site. Hosting platforms offer a “staging” environment to enable QA teams to run their tests on a production-like environment. Microsoft Azure offers App Service Deployment Slots, for example. These instances run on your production resources and sometimes consume similar APIs that the production environment would have.

Since the instances consume the resources from your production environment, they can also be open to requests from external sources, such as the Internet. You should use networking profiles to hide the services that you do not want to be accessible to the public Internet. Your engineers can access those resources by connecting to a central VPN network.

If I access the resource that I deployed on Azure (the App Service) previously, under the Networking tab, I can access the settings and feature support for various networking components, as seen in Figure 6-2.

You can add solutions to a virtual network, and they can be accessed by the people with a VPN installed. The simplest way to restrict or grant access to a resource is by configuring the “access” feature on the resource (on Microsoft Azure, it’s known as Access Restrictions). Figure 6-3 shows the blade from Microsoft Azure that you can configure.

The values added to the fields in Figure 6-3 are temporary and will not work for your production case. But this demonstrates how you can restrict access to an entity or grant access to an entity (where “entity” refers to an IP address or a range of IP addresses). You configure the priority to define the rules. These settings become part of your infrastructure and you can version-control these values. They are also visible in clear-text in the template. Figure 6-4 shows a template generated for this infrastructure setting.

As shown in Figure 6-4, the IP address configurations have been created. See the first element in the JSON “ipSecurityRestrictions” array. We can create more policies to further control how our application is accessed. If you download the template and version control it, you can review the changes to network visibility in future versions. Your code reviewers can review the changes in each file and separately accept or reject them. Your infrastructure will also become more transparent, as it shows which resources are created and how they are being used. You will also find these configuration settings in other cloud platforms, as well as DevOps and IaC tools like Terraform.

You can map network access restrictions on control panels of your website too. Normally, control panels are hosted on a private port, which is not publicly open or known by the customers. A well-known hosting provider will use a specific, common port. For example, Microsoft Azure also provides a control panel for operations teams to check the status of its resources. The control panel is available at {app-name}.scm.azurewebsites.net. You must configure policies to restrict unwanted access⁶ to those gateways too. Microsoft Azure provides a mechanism to either copy the default settings from the web app or configure the settings separately, as shown in Figure 6-5.

Disabling the access will protect your control panel from any public access while providing public access to your website. You will configure the policies the way I showed in the previous page on access restrictions. You also need to configure firewalls and other protection mechanisms to save your solutions from hacking attacks.

Web Firewalls

Web firewalls are an offering of cloud vendors to protect customers’ properties. A firewall protects your website against several attacks and breaches while it’s in production. Different vendors will offer different services and you can determine which service is better for you. Some of the most important services include the following:

• Online resource protection against hacking attempts. These attempts can be unwanted HTTP requests against a login or authentication URL. WordPress, for example, hosts the login pages at {site}/wp-login.php. A web firewall should protect against any harmful inputs into the fields.

• Remote access from a blocked IP address or a region.

• A way to dynamically modify inputs before they are passed to the server. This has an application in case you detect a SQL Injection problem in your application. You can apply a patch to the user input before your developers update the code and publish a new version.

• A way to rate limit the number of requests by a remote IP address. The rate limiting can be done based on the total requests or the average requests in a certain time span.

Cloud platforms offer web firewalls as a service that you pay to receive. It is not necessary to add the paid services in your infrastructure if you do not need to host manually. You can use the resources on top of your infrastructure to provide services. If you follow this approach, this opens up your solution to unknown problems and undefined application behavior.

Imagine you applied a security patch because of a potential SQL Injection or XSS scripting bug found in your application. Unfortunately, your infrastructure crashed and had to be recreated on the cloud. If your IaC contained the settings for the web firewall, then it would continue smoothly. Otherwise, your application will be open to those bugs again. Therefore, you should consider open tools such as Terraform or Ansible to apply your infrastructure-level changes. They offer better automation and development experiences.

On Microsoft Azure, this offer is provided as Azure Front Door⁷ (as seen previously in Figure 6-2). This service provides web firewalls and other performance improvements. Moreover, Azure products provide an integrated monitoring service so you can better understand how a product is being utilized. You can create new instances of Azure Front Door, as shown in Figure 6-6, for your web application (a dedicated instance for this specific application).

After creating the instance, you can use Azure Front Door to configure how a customer can access the resource and what other policies to enforce on each (or all) HTTP request. Figure 6-7 shows the page that you get the first time you create a resource.

You can see that the portal shows you different settings for Front Door that can be configured. These settings control how the general public can access your services. You can add more web apps as a backend pool for load-balancing purposes. You need to configure how your applications are accessed, such as by using HTTPS for example.

Azure Front Door is a simple and effective way of configuring your networking resources on Microsoft Azure. Your operations team can further configure the security policies on a web application by preventing a known-attack-route request. Azure Front Door offers the integrated solution for web firewall. You can find it below the Front Door Designer setting, as shown in Figure 6-9.

You can use these configurations to create custom policies and prevent requests that match a potential breaching format. There are built-in policies to protect your web app against any known vulnerability attacks. OWASP is one such category that Microsoft Azure uses to protect your web apps from external threats. You can find these policies under your Web Application Firewall portal, as shown in Figure 6-10.

There are more settings and attack profiles in the list than the screenshot can show. There are profiles for XSS, SQL Injection, HTTP protocol attacks, and URL and path traversal (such as passing /../ in the URL). You can always write the code to prevent these from within the application. This product can help protect your application without the request reaching your application and consuming your resources (every conditional block takes some CPU and RAM resources on your server).

The problem with this solution is that it’s not integrated with your infrastructure; remember what I mentioned a few paragraphs ago? This Azure Front Door instance is created outside the Azure App Service and you need to have its template downloaded and ready for redeployment.

Figure 6-11 contains the template for Azure Front Door, and it contains the settings for the backend pools. This is how Azure manages the infrastructure settings. One potentially serious thing to note here is that your application is directly accessible. You need to prevent direct access to your website if you are using services like Azure Front Door. You might need to place your resources behind a VPN.

Note

Other cloud vendors will provide a similar service in their own naming conventions. It would take extra time to discuss those solutions and replicate what I did here.

If you have any security recommendations from Azure about your products you can find them under the Security tab on the applications. Azure Security Center offers recommendations and tips to secure your products. Security comes in the form of performance improvements too. If your products have multiple ports open, you can disable some of them to prevent your programs from listening on those ports.

SSL and Encryption

You can also automate the security layer in your application. Most orchestrators and online platforms offer configuration settings for SSL and TLS. With the addition of Let’s Encrypt to the picture, developers do not need to worry about the licensing and other costs for the addition of a security layer. You can automate your way to capture a fresh copy of SSL certificate for your domain and provide a service. You can also integrate premium versions of SSL certificates from DigiCert and other authorities if your business requires that. Automation can help you capture the certificates and apply them quickly. The community of Let’s Encrypt users has provided extensions and scripts that can do the certificate request work for you. Figure 6-12 shows the extension for the Let’s Encrypt certificates that I have installed on Microsoft Azure App Service.

If you cannot find the extension, you should try “adding” the extension first. This extension lets me perform the task of capturing a fresh SSL certificate for my website. The requirements are simple—I should own the domain for which I am requesting a certificate. The rest of the job is done by this extension. Free SSL, and a forever and trustworthy relationship with the customers. If you are using a VM, you can run the customized scripts on your machine as well.

Every cloud platform offers the SSL certificate-purchasing feature that lets you purchase a new SSL certificate from the vendor. The benefit of purchasing the certificate from the vendor is that you do not need to configure the certificate to enable it. The vendor will do that part for you. The pricing and the support depend on the vendor. Figure 6-13 shows the SSL certificate purchasing page for Microsoft Azure.

The certificate is valid for one year and provides a good encryption algorithm (SHA 256). If you use other cloud vendors, you can purchase an SSL certificate from them. For example, Figure 6-14 shows the SSL certificate selling page for Alibaba Cloud.

Alibaba Cloud offers cheaper solution hosting options; it is unclear to me why their SSL certificates are so expensive. Nonetheless, I do not recommend purchasing SSL certificates unless your business requires it. Let’s Encrypt certificates are more than capable of providing a security layer for your websites and can build trust with your customers and search engines. Paying $70 USD per year for SEO is not expensive, but it is not needed when you can use Let’s Encrypt to do the same task. If you are working in, let’s say, Fintech, then you should purchase a premium certificate with maximum support by the certificate authority to protect your online and physical identities. A customer is likely to trust an entity that has their physical identity verified, such as an office building. Premium certificate publishers verify your identity before releasing a certificate, which is necessary for an enterprise.

Just as I mentioned in the “Docker and Containers” section, you must always be ready for change. Just recently, I read that a Let’s Encrypt SSL certificate provider was revoking around three million SSL certificates. Which means, three million certificates will be invalidated on March 4, 2020⁸ and users will see a Red Screen of Chrome⁹ because the certificate is not valid anymore. The solution is easy for the domain owners. Let’s Encrypt provides automation scripts and jobs that perform all the heavy lifting. For the Ops teams, this is the kind of job they need to take care of. I have more than four SSL certificates deployed with my websites and it would be a headache to rerun the jobs and capture the certificates manually.

If you can configure the DevOps pipeline to automatically fetch an updated SSL certificate on an as-needed basis, please do. Most cloud vendors do support jobs, such as WebJobs on Microsoft Azure. These jobs can be used to run periodically or ad hoc.

API Management

So far you have seen different resources provided on the cloud that make it easier for you to configure how customers connect and interact with your resources. If you own an API that is to be consumed by customers (or by your own applications), you should consider hosting the API behind an API controller. There are several options to describe your API, such as Swagger. These profiles make it easier for your customers to access the service or try it out before purchasing it.

There are more services that you can use with the API Management to control your APIs than you can write and integrate manually in your APIs or servers. Custom software development includes development and maintenance costs for each feature. Cloud-hosted API Management solutions provide a turn-key solution to provision, control, and manage your APIs at any scale. Of course, every vendor will have its own definition of the service that it is going to offer you. You need to check this with the software vendor for more information. Most API Management software comes at a cheaper price for all these offers. API Management software should become part of your infrastructure and should be deployed with your resources. API Management is software published as a service for you, but it should be generated as part of your infrastructure deployment, using IaC.

I will also introduce how you can remove customers from subscriptions as needed. To start with this, create a new instance of API Management in the Microsoft Azure portal, as shown in Figure 6-15.

You can select the Developer subscription to try the product before purchasing a subscription for your APIs. It will take approximately 15-30 minutes to deploy and set up your API management service, so give it the time that it needs.

Once the deployment is done, you will see the dashboard page for the API Management, as shown in Figure 6-16.

The dashboard gives you complete access to your production as well as a developer side for the projects. The dashboard is where you can get an overview of the current status of your application. You will see the number of requests and how they are performing on the cloud. Azure Monitor can be used to further investigate the performance for your product.

You can allow developers to visit the developer portal and explore the API offerings. Your production gateway will always be created and hosted at the endpoint that Microsoft Azure provides. You can also map your custom domains to the Azure’s endpoint to offer branding. The default API shown in Figure 6-17 is added by Microsoft Azure; it lets you test the functionality of the product.

You can create and add your own APIs to showcase them to customers who visit this developer portal. To add new APIs, visit the APIs portal under your API Management subscription. You can add different APIs, as shown in Figure 6-18.

These API configurations come in different shapes and sizes. Some of these configurations are pure XML-based configurations (such as SOAP-based Web Services) and some are JSON-based documentation for your web APIs.

You will notice that Microsoft Azure provides first-class support for Function App. Azure Function apps are serverless applications that are developed, deployed, and operated on Microsoft Azure. They are APIs in nature and perform well in the world of IoT and Edge Computing.

Each API that you add to the product will in turn be added to its IaC code. Figure 6-19 shows the default API (Echo API) added to our API Management script.

Other settings that you will make in your application will be added to the template as well. You can deploy the template as needed, and always version-control this template when you are done with it. You can use different approaches to authenticate the users. The simplest of them all is the HTTP-based authentication (bearer tokens). You can use OAuth, OpenID Connect, and many other credential formats. Figure 6-20 shows a list of the available sign-in options.

API Management offers a basic username/password combination for user accounts as well as other settings. A simple approach to managing the authentication is by using self-signed certificates. You can generate them for free and deploy them on Azure as well as on client devices. You can see the Certificates tab under Security. Public/private certificates enable a secure option to authenticate the devices with a central server.

Now let’s look at an example of how we can rate-limit the service. Rate limiting is applied to the APIs individually or to the groups that subscribe. Different vendors offer this service in a different order, or with different specifics. Microsoft Azure offers a different approach. It allows you to apply the API rate limiting as well as quota limiting to the groups. You can control the number of requests that a customer can send to your API, thereby decreasing or controlling the load on your APIs. See Figure 6-21.

This is a product in our catalogue, a Starter product. There is a default policy of 100 calls every seven days (604800 seconds = 7 days) and a rate limit of five calls every 60 seconds. You can add your own complex policies that will further control how a customer can call the APIs. Note that this is the product that the customer will pay for. A customer will get a subscription (an API key in the case of Azure API Management; other vendors have different scenarios) that can be used to perform these requests. On every inbound request from a customer, these rules apply and will limit their requests if they exceed their quota or rate. This scenario explains the workflow: Request number 1 and the response are shown in Figure 6-22. Note the response time as well as the response.

This is a valid response (200) from the server with details. Figure 6-23 shows another request that goes to the server; note the response time as well as the actual response.

This request is processed rather quickly and the response is provided to the customer. Now, when another request is made (this will be the fifth request in reality, as I did not print the intermediate requests here; you can try it on your own machine), Azure returns the response shown in Figure 6-24.

Now, as shown in Figure 6-24, the response is 429. The server indicates that the actual number of requests has exceeded the expected number of requests. You also get this information in the body of the response. The Retry-After: <value> header is added to the response headers and you also get a message in the body.

You can also issue notifications to your customers as needed. For example, when a customer joins your platform, you should onboard them with any information they might need to know. That is where the Notification Templates come in (see Figure 6-25).

You can edit the templates as needed.

So, in a nutshell, API Management provides a good umbrella service for your hosted solutions for customers. You get to create the groups to control how customers are using your product. Application of policies on a group of customers is easier and ethical as compared to preventing the whole product userbase from accessing the application fully. Several online solution providers use this approach to earn revenue from their solutions and provide a limited set of services to the customers for free.

Secure Vaults

Secure Vaults is an advanced feature of a hosting platform that allows you to keep your sensitive information such as (but not limited to) connection strings, API keys, certificate private keys, and other private and confidential information in a locked environment. For example, say you have a web application that uses the configuration settings saved in a cloud environment, as shown in Figure 6-26.

You can see that the values are hidden, but you can simply click to show them. To hide these values, you might need to remove the user from the group that can see these values altogether. In most scenarios, that is not applicable. You need a separate environment to store the keys that do not enable a preview of the values (without a password, of course).

Every platform offers this functionality differently. Microsoft Azure has a product called Azure Key Vaults that allows you to write the keys to a secure vault (FIPS 140-2 standard compliant vaults). GitLab and GitHub enable you to add private information in their own security channels. It does not matter which service you use, just make sure that if you want to embed your information, you save it in a secure channel that does not allow other users to preview the information.

System Failure and Post-Mortems

If you have prepared for the worst and applied all the configurations that are necessary to secure your platform as well as the customers, you have done your part. Internet solutions are meant to crash, and that is a pattern adopted by many online solution providers. Netflix, for example, uses the Chaos Monkey¹³ tool, which automatically terminates the virtual machines that run in your production environments.

Customers also use hybrid cloud solutions. If your company has its own datacenter and is considering migrating to a public cloud platform or has a customized cloud solution, you should consider applying for a backup plan. Online cloud platforms offer you a backup plan on their own infrastructure with an SLA for availability. You pay a very cheap amount every month and they provide you with availability option from their datacenters. If your application crashes on your premises, your customers will continue to access the service from the cloud. These services are available not only for web applications but also for complete virtual machine migrations. This enables your solution to make the most of the hybrid environment and provide the availability that your customers would expect from you.

If your software fails and you do not have a backup plan, you should at least have a graceful exception handling in your application. ASP.NET Core¹⁴ lets you handle the exceptions gracefully and shows a helpful message to the customers. Sometimes an application is required to return a status code to the browser, so that browser can also remember what happened. This can help your customers with accessibility requirements better understand what happened. If you return a status of success but the screen message says something failed, screen readers might miss the context and mislead the customers. Your UX should be consistent in the case of exceptions as well as successful execution of the code.

.NET Core has a vast ecosystem of logging solution providers. The oldest of them is the ELMAH¹⁵. You should use it to track all the exceptions and errors happening in your system. A brief report of the exception and other metrics can help you perform a suitable post-mortem of the problems in your application. DevSecOps recommends quick response against a bug or an exception. You should work on the exception as soon as it shows up in your application’s metrics and analytics reports. You will use Azure Application Insights or Google Analytics to track your online solutions. You can use Firebase and Visual Studio App Center to manage the mobile apps developed by Xamarin.Forms. All these online solutions provide a reporting solution for you to track. You can learn what went wrong and how to improve the application to prevent the exception from happening again.

Infrastructure Rollbacks

So, you have faced a problem with your system. Maybe the problem was with a recent update you made to the system. You can always roll the system back since you integrated the cloud platform with a DevOps and IaC tool, such as Terraform.

Most cloud platforms enable you to perform a roll back as needed on their service. You should not rely on these products and features on the cloud platform because they can change anytime. Microsoft Azure is in favor of using Terraform instead of their ARM templates because of the features that Terraform provides. The features, community-support, and cloud platform it targets all make it a suitable product to be used for IaC purposes.

If you want to get more technical in the deployments and their history, you should read about how Kubernetes¹⁶ enables rollbacks for the deployments that are made on their platform. Note that you can also manually provide the container label to pull the specific container and refresh the deployment. You can perform this action on other platforms as well; we discussed the Azure App Service platform that supports Docker containers. Always choose automatic updates and operations over manual tasks and configurations. Manual handling of the infrastructure is prone to errors and likely to cause system failures, crashes, and service disruptions. Manual handling of the system also is less auditable and cannot be checked for underlying problems. Automatic operations are more likely to be verified by CI servers and are easier to be rolled back when they cause a problem. Version control systems such as Git enable us to tag a specific version of history and label it. We can use these labels to specify what that state does and move back (or forward) in time as needed. The rollbacks become easier and are automated.

Summary

Your infrastructure contains resources beyond your .NET Core code. You are responsible for securing those services and products as well. Some of these services run on top of your .NET Core, so it does not matter how secure your code is. Improving the infrastructure security and performance requires an understanding of different computer science concepts; trust me, not everybody knows them all and everyone does Google the solutions every now and then.

Our hosting environments utilize Docker containers or a similar technology to improve the developer experience. Many cloud platforms have Docker and other services integrated into their platform to provide a first-class experience to the developers and operations team. Although cloud vendors make security and privacy their top concern, it is your responsibility to make sure the hosting environment is secure and protected from external attacks. You might need to purchase a subscription if your cloud vendor requires it from you. The solutions range from basic rate limiting and load balancing, to SQL and XSS prevention, to SSL and encryption application on your infrastructure.

If your application resides in a secure environment, it can better perform the services that it states to perform. There are services that target different important areas of software production. If you are building APIs and hosting them on the cloud, you can create an integrated experience (like a marketplace for your APIs) on the cloud for your customers. This enables your customers to visit a central place to learn about your APIs and try them out.

I also mentioned how you should protect your resources from public repositories and public access. This area applies directly to mobile and other handheld platform devices. If you are developing applications for Android or iOS, you must never hard-code the APIs and other external or custom API keys in the application. Your applications are likely to be reverse-engineered. If an application is reverse-engineered, it is likely to expose the API keys during the process. An attacker can then use that API key to make requests to the server.

In the end, I discussed how you can improve the system’s performance, availability, and replication with public clouds, private clouds, or hybrid cloud approaches. Hybrid cloud applications are the most applicable approaches in this modern time. Not every business is ready to take their solutions to the cloud because of the complex architectures of cloud-native solutions.

Now that you know how to improve the production environment, in the next chapter, I will discuss compliance and other regulations that apply to your perfect solution! Developing the solution and building it with your favorite IDE is not enough to publish a solution to the market. You need to make sure that it is ready to serve the customers in the markets that you are planning to target. Compliance and regulations, such as GDPR, require lots of developer time (if you are an individual) and you should take some time to understand what they mean for you and your application.