Oracle Linux and scaleable microservice architecture based applications

For a long time the answer to the question how to handle the increase of transactions on a system was vertical scaling. Simply putting in more memory or buying new servers with more processing power. This answer was mainly driven by the fact that most applications have been build based upon a monolithic architecture principle.

In a monolithic architecture principle applications are developed as one single application where all the components (libraries / functions / procedures) would live on a single server and cannot be separated on different servers. In some cases these applications are developed in a way that two of those instances can work together in a clustered manner. However, in many cases the primary way of deploying them is to deploy them on a single server. If it turns out that the use of the application grows and due to this the application gets slower the common answer was, add more compute resources. Adding resources to a server to cope with the growth in demand for compute power is seen as vertical scaling.

Databases, Oracle databases, have adopted the model of horizontal scaling already for some time by using Oracle RAC. When the demand for more compute power grows additional nodes can be added to the RAC cluster. Adding additional nodes, rather than putting more compute power in a single node, is referred to as vertical scaling.

Also in the area of application servers and web servers the vertical scaling model is not something new. Creating a cluster of, for example, Weblogic application servers and loadbalance the load over the members of this cluster is something that already has been done for quite some time.

However, even though Weblogic clustering and Oracle RAC clustered databases are available it is often seen that the foundation of an architecture is not taking into account the vertical scaling model. When you intend to build an application that will make optimal use of vertical scaling you will have to ensure that you incorporate this directly in your architecture. It is good practice to ensure that your application (landscape) will be able to scale vertically even in cases where you do not see the direct use. This is to ensure that if you ever need to scale in the future you do not have to redesign the application from scratch or recode large parts of it.

One example of an architecture principle that will provide you an optimal vertical scaling model is the use of microservices. microservices is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task, facilitating a modular approach to system-building.

Commonly microservices will communicate with each other by using the HTTP protocol, calling (REST-)API’s via HTTP has the advantage you can make use of all the scaling and load balancing options that are commonly available and are already proven technology for years for deploying large web enabled applications.

monolithic application design
By implementing microservices you will avoid building an application based upon a monolithic application design as shown in the below diagram.

Some of the characteristics of an application build based upon a monolithic application design are:

• Application has single code base with multiple modules 
• Large internal dependencies between components and functions
• Components invoke one another via language-level method or function calls
• In general difficult to scale up and down when the situation demands this
• Poor resilience towards component failure, small disturbances often result if complete application unavailability 
• Complex to maintain and difficult to change or integrate with new systems
• Poor re-use of developed functions and components outside of the application
• Commonly depending primarily on vertical scaling of the hardware and not capable of handling horizontal scaling
• Serial development process, takes in general longer to develop.

Microservice application design 
Microservices allow you to build multiple smaller components, capable of running all on one or multiple dedicated machines instead of running the entire application on one single server that cannot be scaled easily. An example of the same application as above, however build upon a microservice architecture, is shown in the below diagram:

Some of the characteristics of building an application based upon a microservice architecture principle are:

• Application is broken down in multiple (micro)services, each having their own code base / programming language
• Components are loosely coupled and communicate based upon API’s and HTTP calls with each other 
• Easy to scale up and down, both vertical as well as horizontal. Each service can run on one, or multiple machines
• Highly resilient towards component failure due to the distributed system principles and the use of multiple small machines. 
• Ease of changing components and integrate with new functions.
• Provides an easy way of function re-use outside of the original application realm.
• Parallel development process, takes in general less time to develop.

Implementing this model provides both advantages in scaling as well as in ensuring your application is resilient against component failure. In the below diagram you can see that some components are scaled to a four node implementation and have presence in two datacenters. This provides both benefits on load balancing as well as improved resilience

Building a node
A node, when used in a microservice architecture will be a machine or virtual machine running one or more microservices. In general this is Linux machine running an application capable of providing an API. One way of building node’s and micorservices is making use of Flask, Flask is a micro web application framework written in Python and based on the Werkzeug toolkit and Jinja2 template engine. It is BSD licensed.

Flask is called a micro framework because it does not presume or force a developer to use a particular tool or library. It has no database abstraction layer, form validation, or any other components where pre-existing third-party libraries provide common functions. However, Flask supports extensions that can add application features as if they were implemented in Flask itself. Extensions exist for object-relational mappers, form validation, upload handling, various open authentication technologies and several common framework related tools. Flask is ideally suited to build microservices on.

In the below diagram we show a node build based upon Flask in combination with NGINX,  NGINX is a free, open-source, high-performance HTTP server and reverse proxy and running both Flask as well as NGINX on an Oracle Linux operating system. In this example we have selected specifically Oracle Linux as microservice nodes are commonly used in deployments that demand high availability, extreme performance and extreme scaling. Oracle Linux can provide this in combination with Flask and NGINX.

Making it virtual
As one of the advantages of microservices is that it can scale easily it is commonly a good practice to ensure that your nodes are based upon a virtualization strategy. As we use Oracle Linux in our example it also makes sense to use Oracle VM as a virtualization layer. When needed a new node with the associated microservice can be created and can be added to the loadbalancing.

When monitoring your entire footprint with Oracle Enterprise Manager you can create a solution in which Oracle VM automatically creates new nodes for you when performance drops due to an increase in the number of requests. Oracle Enterprise Manager will then be able to scale down again as soon the number of requests goes down. By implementing such a self scaling and self healing solution you are assured of a always performing and always available solution to your users. This will require good thought on what kind of hardware to use; in this case it would be a good solution to use for example the Oracle Private Cloud Appliance. The Oracle Private Cloud Appliance is an engineered system, developed by Oracle, specifically to run elastic and changing landscapes based upon Oracle Linux and Oracle VM. 

Oracle building blocks for future enterprise services

As we observe the direction enterprises are heading into with regards of their IT footprint we can observe a number of interesting trends. None of them are new, however, we see them picking up more and more momentum and becoming the new standard within enterprise IT. If we take a look at some of the directions enterprises are moving into and what the demands are from the internal users in the form of business departments we see the challenges faced.

The questions asked by the business are in some cases against the traditional way of working and doing things. To be able to implement them and satisfy the business some radical change is needed in some cases. Not only in the way IT departments work, also in the way the entire IT landscape is architected and how the entire IT landscape traditionally is build.

To be able to move from a traditional way of working, in most cases, a combination of application as well as infrastructure modernization and rationalization is needed.

To read the full blogpost please visit the Capgemini.com Oracle blog.

Push API solutions for open and linked data

The internet has been growing at a rapid speed which was most likely not foreseen by a lot of people in the beginning. When Tim Berners-Lee added HTML and HTTP to the internet mix and by doing so opened the possibilities for the world wide web as we know it today he most likely was also not foreseeing what this would become, not even in his most wildest dreams.

As we are now becoming more and more used to the daily influence of the internet and the possibilities that it is offering us we are also trying to find ways on how to improve to the current state of it. We have had the web2.0 revolution which came down to a more social and a more interactive internet where people could more easily add to the content instead of only consuming it as a reader of web-pages. Many see the next big paradigm shift for the internet in the Semantic Web. The idea of the Semantic Web includes a lot of components from open-data, linked data, micro-formats and the internet of things / the internet of everything till big-data concepts. It all comes down to how we think about data and how data will play a role in the next version of the web.

In the below video you see what the vision from Tim Brenners-Lee is on the next version of the internet which he posed during one of his talks at TED.


 What it comes down to is the desire to provide data in an open format. Not necessarily in a nice and flashy website or a closed website however rather in the pure and raw format. This in an open format like XML or any other usable format.

By unlocking this data there will be directly involved the unlocking the potential of a lot of new options. When people do have access to raw data you can create new applications and come to interesting insights. currently the most data is still in closed silo's and not accessible to the public or not accessible in an open way that you can use it in a way you can build new applications around it. When the world starts with adopting the open-data model and the linked data model there will be a sprawl of new options coming to the public.

Even though all the above mentioned things are coming our way and will change the way the internet is used and seen by the public one important architectural part is missing in my opinion, or rather, is not given the attention it deserves. The missing, or rather under appreciated part is the role that push interfaces and API's will play in this new revolution. If we look at many of the new solutions, models and formats they are all based, or primarily based, upon a pull architecture.

If you draw a high level architectural representation of the current state in which applications are commonly are developed you will get something similar like the drawing below.

The custom application could for example be a web application that tracks flight information from a major airport and shows this to visitors of the website. The website itself is represented as the "Presentation layer" in the above diagram. Every time someone is logging in to the website the code will query for the most recent flights in the local database. However, to ensure that the local database contains this information it needs to be filled with data that comes from the "data owner". What you commonly see is that there is a scheduled program to download the basic information from the "data owner" data API and it is stored in the local database. The moment a user clicks on a flight the web application code will do a "online" query to the "data owner" to get the more detailed and latest information about this specific flight. 

In essence there is nothing wrong with this model and it is serving its purpose. However there are more and better solutions to do this which makes the development much more easy and ensures that applications are becoming faster, less prone to issues and less resource intensive on both the "custom application" side as well as the "data owner" side. 

A more favorable way of doing this is by making use of a push API rather then a pull API. In the below diagram the same solution is shown however no making use of a push API initiated by the data owner. 

The implementation of this model makes a lot of sense as it is removing a lot of unneeded communication between the customer application(s) and the data owner. Also missing an update is less likely to happen and new information, in our example flight information, is in real-time available to all who custom applications that have subscribed to the push interface from the data owner. 

In the above implementation, as soon as a new flight is known at the data owner it will send out a message to all the subscribed applications. By doing so the data owner knows that all the other applications are now aware of the new flight and might, if needed, query additional information via the "direct remote data access" method to the more traditional data access API. In some cases the real-time push API will remove the need for a more traditional API however in most cases there will still be a need for this. 

The hurdle for implementing this model is the need to develop standardization for communication between the data owner and the custom applications. Ideally the communication between both parties is arranged based upon the HTTP protocol and JSON or XML messages are exchanged between the 2 parties as shown in the image below. 

From a technical point of view it is not hard to implement the communication from both the "data owner" side for a push data API nor is it for the receiving side complicated to create a data update receiver who will receive and process the data send by the data owner. 

The biggest hurdle in this process is to ensure that the construction of the message is correct and contains all the needed information that the receiver of the receivers might need and that this is done in a functional format that is not only for a single receiving application usable but for a large set of external applications. If we take for example a look at the work done in the field of ontology for annotating offerings and other aspects of e-commerce on the Web by GoodRelations or the work done by schema.org you will see that developing a good standard is something that is not to be thought of lightly. However the below illustration might show the need for such standardization of message formats on both a more functional level and a technical level.

Commonly a custom application, for example a web portal showing flight information, is not making use of a single source. If, for example, you like to build a web portal showing all the incoming and outgoing flights in real-time or near real-time for the city of London you have to work with 11 different data providers. London is having ten "normal" airports, Luton, Stansted, Northolt, Stapleford, Heathrow, London city, Biggin Hill, Blackbushe, Farnborough and Gatwick. They also have a helicopter only airport named Battersea.

From a technical point of view it would be a great benefit if all those airports do make use of the same way of providing a push API interface to all push the information in the same manner. This way the developers of the custom applications that will connect to it will only have to develop a single data update receiver and simply subscribe to all the 11 airport push interfaces instead of developing 11 different receivers. Next to this the data providers, in this case the airports, can make use of an already developed standard data format and can potentially decide that they will develop a push interface together so they can split costs.

From a functional point of view a standard makes sense because you will know exactly what data you will get and which format. From a functional point of view this is not the technical format but rather the functional format. For example, if the data owner is also sending out weather information per flight, it would be good if all data owners do this in the same manner and all the information is in the same functional format. Meaning, temperature is for all data owners in Celsius or it is for all data owners, who comply to the standard, in Fahrenheit. This way you always know from a functional point of view what the data means and how to interpret this.

In conclusion, push API implementations will fuel the next generation of the internet in my mind and they will ensure that the web becomes (even) more real-time and data rich. The flow of data will help sprawl new initiatives and will help create new companies and great projects. For this however there will be a need to ensure that standards will be developed, not only on a technical implementation level, however even more important on a functional level where the standards will define which information in which format will be provided to the data consumers. 

Understanding the Oracle Communications product portfolio

A little less then a year ago Oracle completed the purchase of Acme Packet. "Acme Packet enables trusted, first-class delivery of next-generation voice, data and unified communications services and applications across IP networks for service providers and enterprises. The company's solutions are deployed by more than 1,900 service providers and enterprises globally, including 89 of world's top 100 communications companies".

By purchasing ACME Packet Oracle has extended its product portfolio extensively and create the Oracle Communications product group. The current Oracle Communications product group is shown below in overview diagram;

The current naming of the products within the Oracle Communications product group can be a bit strange for people who are used to the original naming used by ACME Packet. For them, and for people working with Oracle Communications products it can be good to have some understanding of how Oracle has grouped products in the product group and sub product groups.

In general Oracle Communications is buildup out of 4 main product groups, Hardware, Network Session Delivery and Control Infrastructure, Enterprise Communications and Network Visibility and Resource Management. The last product group, the Network Visibility and Resource Management group is divided in two separate sub groups; Oracle Communications Session Delivery Manager and Oracle Communications Session Monitor.

When looking at the Oracle Communications website the total reach of the product portfolio is a lot bigger then what you can see above and the full integration possibilities become clear. By combining the products from "pure" Oracle Communication and combining them with other products from Oracle you can build a near red-stack solution for your entire communication delivery within your enterprise or have it as your core business to end-users outside of your company.

It is a shame that this part of Oracle is overlooked and it is especially a shame that it is overlooked by a lot of the integration and solution architects who design software solutions and commonly stop where direct communication is needed between humans and we leave the computer-to-computer communication.

What to keep in mind when reading a best practice

When developing an technical deployment architecture for a company it is always good to base your architecture on the best practices. Best practices are offered by a number of sources and when reading the best practices it is good to understand where they are coming from and if there is a "second agenda" in the best practices that is offered.

In general the best best practice is are to be found by independent organizations that provide industry best practices. Next to this a good source of best practices can be the numerous blogs that can be found online. a lot of software vendors do provide best practices and also implementation companies do provide best practices. One thing you have to remember though is that there is always the change that the people from the software vendor and/or an implementation partner do write a best practice without keeping in mind a specific business case.

In real world deployments every additional piece of software and hardware is an additional cost on the budget. This additional cost in the budget should be accompanied with a valid business reason. When someone writes without keeping that in mind, or even with the intention to add additional and costly features to the design, the costs of your deployment architecture might not weigh up to the business benefits and needs.

When reviewing a best practice always try to keep the following things in mind:
 - Is the goal used in the best practice in line with my business need
 - Is this best practice possibly written with a second agenda
 - Is this best practice including higher demands then in my situation
 - Is his best practice only focusing on a single vendor solution stack and are the options to include solutions from other vendors.

If you keep the above point in the back of your mind best practices you download from software vendors are very usable.

Oracle enterprise reference architecture

Everyone who has been watching Oracle and the strategy from Oracle closely will have noticed that they have been growing by acquiring new products and companies and by developing new solutions. When you look at the current portfolio of Oracle you will notice that they can provide solutions in a wide range of fields. One of the daunting tasks for Oracle is providing an overall strategy and architecture to combine all those products and product lines into a reference architecture which can be used and deployed by architects at there customers and at system integrators. To help architects with this Oracle has developed the "IT Strategies from Oracle" or in short ITSO. ITSO helps customers to find there way in the wide range of products and solutions and build IT strategies and architectures based upon the Oracle best practices and blueprints.

The general starting point for ITSO is the overview image of the IT Strategies from Oracle from which you can drill into details. 

As you can notice in the above overview image the IT strategies from Oracle do consist out of 3 main components. These are: "Enterprise Technology Strategies", "Oracle Reference Architecture" and "Enterprise Solution Designs". To fully understand the the IT strategies from Oracle it is of vital importance to understand the meaning of the three main components and there role within the overal strategie from Oracle. 

Enterprise Technology Strategy

The Enterprise Technology Strategies or in short ETS is the integration of the vertical positioned technologies into the core part of the ITSA, the core part is the ORA within ITSA. Within the technologies mentioned in ETS you can find technology paradigms like SOA, BPM, EDA, etc. From within the ORA there is a connection made to the verticals within the Enterprise Technology strategy. 

Oracle Reference Architecture

The Oracle Reference Architecture or in short ORA. ORA is a logical architecture reference showcasing how to build and deploy enterprise class solutions. The purpose of ORA is to provide a reference architecture for designing, building, and integrating solutions based on modern technology from Oracle and other vendors. The reference architecture offers architecture principles and guidance based on recommendations from Oracle product development architects and field experts. Information provided by ORA gives architects an understanding of how to design solutions for the Oracle environment and best leverage its capabilities.

It is important to note that One of the key concepts of ORA is to be vendor neutral  and product agnostic. This means that within theOracle Reference Architecture core document no Oracle products are specifically promoted. Having stated this, there is an exception made by Oracle that they will name specific vendors and products in case that this is needed to clarify certain principals or to be used as an example.

Enterprise Solution Designs

The Enterprise Solution Designs or in short ESD is used to provide insight in specific industrie  perspective. It combines specific industrie requirements into solution designs  which leverage the information in the Oracle Reference Architecture and in the Enterprise Technology Strategy documents.

The entire stack of information provides architects working with Oracle products and/or developing architectures for enterprise grade solutions. This information can be valuable to craft a overall architect strategy which you can follow and use as guidance in creating a strategic roadmap for the future and set design principles for a team of architects. 

Deep application boundary validation

When developing an application security is (should) always be a point of attention. Unfortunately security is commonly a point of attention that is addressed when architects discuss the implementation of the application. At that stage security comes into play when people are looking at how to put in firewalls, host hardening, database security and communication with other servers and services. These are all valid points of attention and do need the appropriate attention however security should be a point of consideration in a much earlier stage of the process. 

Boundary validation is a method used to validate input coming in from an untreated source into a trusted source. A simple example of boundary validation (and one that is commonly done) is the validation of input given by a user into an application. If we take for example a web based application the input from the user coming from the Internet or intranet is considered untrusted and is validated when crossing the boundary from the untrusted user space into the trusted server side scripting.

This form of boundary validation is commonly done and implemented in a lot of (web based-) applications. Even though this is a good approach this is in many cases not enough. Even for the most simple application this can possibly not be enough. As we are using object orientated programming in most cases one function calls another function to perform some actions, by having functions calling functions (calling functions) it is very likely that if you implement only a boundary validation when receiving the data from the user that is can potentially cause a security risk in one of the other functions.

As an example, during boundary validation of a login function it is checked if the input on a order entry screen against the rules for the order entry screen it can be very well that you have secured against the input of malicious data for this specific function however as the user input is commonly used as input for all other kind of functions it might be that some input that is considerd not malicious for the order entry screen can be triggering a vulnerability in a total different function somewhere down the line. This might result in an attacker gaining acces to data or functionality somewhere else in your application which was not the intention of the developer.

To prevent such an attack it is advisable to not only consider data coming into the application as a whole to consider unsafe however considering all data passed between functions to consider as unsafe. This holds that you will have to do boundary checking at every function and not only the functions exposed to the user. This also holds that you cannot do boundary checking only at the application server, you will also have to make sure boundary checking is done in for, for example, all your database procedures and functions. 

By implementing such a model you will harden your application even more against attacks. Implementing such a strategy is causing more work to be done during coding however this form of attack, even though it less commonly know, is quite regularly used by attackers to gain access to systems and data.

Use Oracle SOA for mobile

We have seen a trend where more and more people start using mobile applications, people start to use there phones and tablets more and more and not only for social things but for all kinds of actions. As the mobile trend is well on its way and is still picking up speed we now see that the same trend is on its way in the enterprise market. Mail on your phone is already common. Large numbers of employees do get their business mail on their phone and use it to interact while not in the office. The next step is that companies are making applications mobile so they are available to employees 24 hours a day 7 days a week on any device.

Issue is however that enterprise applications are commonly complex and often consist out of a multitude of applications and servers. Building a simple mobile application is not that easy and you have to pull information and interact with multiple applications when you are building a single application that can be used in a mobile way. Secondly, enterprise applications are commonly not equipped to be made mobile and are often "old".

Oracle is providing a couple of things that can make your life a lot easier as an architect and as a developer. If you are developing a platform and application that is intended to make enterprise applications (legacy applications) available on a mobile device you do want to look at the Oracle SOA suite and you do want to look at Oracle ADF.

Oracle SOA Suite;
The Oracle SOA suite can help you to design and build a way to interact with a multitude of backoffice systems and tie this into a single point of interaction for your mobile application platform. For example, if you need information from two different systems pulled into your mobile application, do an interaction on this data and ship it to a number of other systems it is not making sense to build all those interactions and connections into your mobile application. It would make more sense to create a communication and interaction model in your mobile application server and use the Oracle SOA suite to take care of all the interactions for you.

This will help you simplify the interaction between your mobile application and the server used to connect your mobile application to and all the possible backoffice systems you need to interact with.

Oracle ADF;
Oracle ADF (Oracle Application Development Framework) is a framework developed by Oracle to develop Java applications. If you are about to develop mobile applications and the needed background services in combination with SOA this is one of the things you do want to look into. Oracle is providing a lot of functions out of the box to interact with the Oracle SOA components as well as building mobile applications for multiple devices.

The below video is showing a quick guide into developing mobile applications with the help of Oracle ADF.

Share healthcare data

One of the most important things to most people is their health. The western world is spending fortunes on medical care and on inventing new medicines and treatments every day. We do however see that one area where a lot of good can be done is still lacking behind. This is the way we handle data in the healthcare systems. Several countries have tried to implement systems to handle and share patient data in a national system. Most of them have failed. The reason for failing are several. Security and privacy are some that come directly to mind.

When you are handling personal data, and maybe even specially when handling medical personal data, is that  we have to extremely careful that the data is used for the correct purpose and is not falling in the wrong hands. However having the option to quickly share data about patients can safe lives and can make the medical costs for handling patients go down.

Currently we are spending money on redoing tests, finding lost data during transfer and making the wrong decissions on a daily basis. Mark Blatt, Worldwide Medical Director at Intel, has some thoughts on this, one of the slides from a presentation given by Mark Blatt shows the collaborative workflows that could be used in the medical industry.

most of us will agree that sharing medical information will help the medical system and will benefit the patient. What most of us do not agree upon is the way how this should be implemented and especially in consideration with patient confidentiality and privacy. Finding the right way of doing this is however, in my opinion one of the big challenges that the IT industry will have to take upon itself together with the medical industry and governments. We all do recognize that the medical costs are skyrocketing and that, if we want to be able to make use of the medical care we against a price we can pay we have to find ways to make this less expensive. In my opinion sharing data can be a big step into this process of cutting down costs.

Below is a part of a presentation given by Mark Blatt;

Understanding Parallel Computing

Some time ago I posted  a blogpost named "The future of computing is parallelism". Here I was discussing the future of computing and the role of parallelism that will be a large player in future computing and system design. Below you can find 2 video's on Understanding Parallel Computing and the Amdahl’s Law.


Amdahl's law, also known as Amdahl's argument, is named after computer architect Gene Amdahl, and is used to find the maximum expected improvement to an overall system when only part of the system is improved. It is often used in parallel computing to predict the theoretical maximum speedup using multiple processors. It was presented at the AFIPS Spring Joint Computer Conference in 1967.

The speedup of a program using multiple processors in parallel computing is limited by the time needed for the sequential fraction of the program. For example, if a program needs 20 hours using a single processor core, and a particular portion of 1 hour cannot be parallelized, while the remaining promising portion of 19 hours (95%) can be parallelized, then regardless of how many processors we devote to a parallelized execution of this program, the minimum execution time cannot be less than that critical 1 hour. Hence the speedup is limited up to 20×, as the diagram illustrates.

source: wikipedia

Oracle DNS-Based Load-Balancing e-Business Suite

Recently Elke Phelps and Sriram Veeraraghavan presented a talk named advanced E-business Suite Architectures" which handled quite some interesting topics. You van check a re-run of the presentation via the weblog of Steven Chan and you can download the presentation also from the oracle.com website in a PDF format.

One of the interesting subjects covered during the talk was the subject of load-balanced configuration for Oracle e-Business suite. This is a very interesting topic because it can help you in several parts of your architecture and your Enterprise IT planning. It can help you load-balance load within one datacenter, it can help you balance the load over multiple datacenters and it can help you with creating a more resilient solution. Within the presentation examples on load balance solutions where given in the form of DNS-based HTTP-layer based load-balancing. We will focus on DNS-based load-balancing, the slide from the presentation given by Sriram and Elke is shown below.

The example used in the presentation from Oracle is talking about Oracle e-Business Suite, however you can use DNS-based load-balancing technology for all kinds of applications and primarily for web-based applications.  In the below example you can see a none load-balanced web-application. A user will request the IP address of the URL (somedomain.com = 101.102.103.101) where the .101 IP is the IP of web-node-0 within the DMZ in DC-0 (datacenter-0). This is quiet straight forward and how all web applications work in essence.

If you are planning for a more resilient solution then the one above, which has a number of single point of failure parts, the first thing we will have to take a look at is the number of web nodes. You can make one web node up and running and have a second standby for when the first fails. This is a fail-over solution in which you can choice for hot standby or cold standby.

A better solution might be to have both web-nodes up and running and have both of them handling load. This way the load can be spread evenly and when one of the web-nodes fails the other can handle the full load. This is shown in the below image where we have "web node 0" and "web node 1". In this situation you have to configure your DNS server to provide the IP address of "Web Node 0" or "Web node 1" when the user requests the IP address of the URL. To provide a good load-balance mechanism you will have to have a round-robin (like) algorithm to make sure the load is distributed among "Web Node 0" and "Web node 1"

"Round robin DNS is often used for balancing the load of geographically distributed Web servers. For example, a company has one domain name and three identical web sites residing on three servers with three different IP addresses. When one user accesses the home page it will be sent to the first IP address. The second user who accesses the home page will be sent to the next IP address, and the third user will be sent to the third IP address. In each case, once the IP address is given out, it goes to the end of the list. The fourth user, therefore, will be sent to the first IP address, and so forth."

In the above example we still have some possible issues. For example; what happens when "web node 0" is down? In the above example the DNS server will still think the node is up and will provide the IP address of the malfunctioning node to users whenever the round robin algorithm decides it is it's turn. Having a smart mechanism which checks the availability of the node and which removes the IP address from the DNS server so it will not be used when the node is down can be considered as a best practice. Having such a heart beat mechanism for DNS should be in your overall design.

A second single point of failure is the DNS server itself. If the DNS server is down it will not be able to provide the needed IP addresses when requested for by a user and it will not be able to balance the load over "web node 0" and "web node 1". It is common practice for most publicly used DNS servers to have a domain registered in a primary and a secondary name server. To prevent your solution from malfunctioning in the case a DNS server issue you should have at least a primary and a secondary DNS server and possibly even a tertiary DNS server. Having multiple DNS servers for a single domain name is within the design of how DNS name resolving works and is not something you should (really) worry about.

The above example is protecting you against the failure of a DNS server and the failure of one of your web nodes. It is however not protecting you against the failure of your entire datacenter. If datacenter DC-0 would be lost due to, for example a fire, your DNS servers would have nothing to point at. You do however have the solution already at hand with the round robin solution in your DNS servers. You can use a dual datacenter solution where you deploy your web nodes in both. Now the round robin DNS server will route users to both datacenters and to both web nodes. Meaning, the DNS server will provide routing to all 4 IP addresses of all 4 web nodes by making use of the round robin mechanism.

As you can see in the above diagram we have also introduced a data synchronization between DC-0 and DC-1 to make sure that the data is replicated to both datacenters. For replication of data between multiple datacenters you can deploy several mechanisms. Some are based upon a solution in the database, some in how the application is developed and some make use of block storage replication. Which one is the best for your solution is something that will depend on a large number of variables like for example; distance between your locations, type of storage, type of application, level of data integrity needed,... etc. making a decision on how this needs to be done however is something that you have to think about very carefully as it can impact the stability, availability, extendability and speed of your application.