Architecture

This is a difficult topic. I have to admit I am still not completely comfortable with all the concepts and functions. However, the thinking is amazingly interesting, and I will take some time to ingest everything. First things first, I will use this post to summarize what I have learned so far. How did I end up reading that kind of work, you ask? Weeeellll, that’s easy :) Brendan Burns, in one of Ignite ‘17 sessions, used the comparison “autonomous vs autonomic” to discuss Kubernetes. This got me thinking on the actual comparison, and aided with our trusted friend, Google, I found a NASA paper about that (https://www.researchgate.net/publication/265111077 _Autonomous_and_Autonomic_Systems_with_Applications_to_NASA_Intelligent_Spacecraft_Operations_and_Exploration_Systems) I started to read it, but it was a bit obscure for me, and scientific English, applied to space research, was a bit too hard for an introduction to that topic of autonomic systems. Some more research, helped by me beloved wife, led to a research thesis, in French, by Rémi Sharrock (https://www.linkedin.com/in/tichadok/). The thesis is available right there : https://tel.archives-ouvertes.fr/tel-00578735/document. This one relates to the same topic, but applied to distributed software and infrastructure, which ends up being way more familiar to me :) The point where I am right now is just over getting the definitions and concepts right. I will try to describe what I understand here about automated, autonomous and autonomic systems. There is some progression from the first to the second, and from the second to the third concept. Let’s start with automated. An automated system is just like an automaton in the old world : something that will execute a series of commands, on the order of a human (or another system). For example, you have a thermostat at home that send the temperature from inside and outside your home to the heater controller. ...

I know, there are tons of materials and training that will explain you how to select between SaaS and custom software. I’ll summarize their usual points, but I wanted to add some details on how you might have to look at the full scope of cloud services : from Iaas, through PaaS, to Saas, and a detour through containers. First the usual discussion, that have seen unfurl dozens of times : why choose SaaS over a custom/on-premises solution? You know the drill, right? On one side, you have full control and can customize the solution. This means the software will be tailored to your exact needs, and you will control exactly what is done with it, how is updated, where data is stored, accessed, replicated, backed-up etc. You will know the exact setup of the deployment, which layer is connected to which other layer, how, where traffic goes, how each layer is protected, and replicated. You will handle failover, high-availability etc. In a few words : you will be the master in your own kingdom. Problem with that path : you are, mostly, on your own. All of these domains I just listed are your responsibility, and you have to have knowledge and skills to handle those. You might need to expand those skills to cover 24*7. You’ll need a strong IT team, in addition to a trained software team. On the other side, you have SaaS : bright new, quick and easy. You set that up in a flash, connect the solution to your other enterprise software, create user accounts and voilà! No administrative overhead, the only skill you have to master is the configuration of the solution. You’ve seen the downside coming : you have absolutely no control over the software, its release cycle, the mechanisms in place to provide high-availability. Sometimes you have some control over your data, but it’s not obvious. In the end it’s your call to choose the balance you need. The cloud has integrated the same choices and solutions. You will have to decide whether you want to use IaaS, PaaS or SaaS. The basic triggers are the same, you choose the right balance between control, freedom and responsibility. Read here a good explanation : https://docs.microsoft.com/fr-fr/azure/app-service-web/choose-web-site-cloud-servicevm I would like to add something to that horizon, something spicier, which could probably give you the best of each solution, provided you are ready to learn some new skills. We had the same discussion several times with our customers, revolving around the limitations of Azure App Service for some Java applications, its lack of control, and how moving from that to a full-blown IaaS virtual machines felt like dropping out of the cloud. Here what we built with some of those customers. We wanted to provide them with the flexibility and ease of use of Azure App Service, tailored to their needs, without adding much IT admin overhead. We had already been running a Kubernetes cluster for our own internal needs for a while, and it was an easy leap to suggest that solution. Kubernetes is becoming the leader in container orchestration, but you could choose any other solution (DCOS, Swarm etc.) Here is a short list of the benefits the customer gained in that solution : • Flexibility of the deployment and settings of the application, down to every Java VM option • Scalability of an enterprise-ready container orchestration, based on a cloud platform that is reliable • Ease of deployment : these are containers after all! The only thing you have to keep in mind here is that someone has to learn and master containers and the orchestration layer for those. Kubernetes might not be the most accessible solution here, but it is, in my mind, the most mature and powerful. One last word, for you sceptics who still believe that Microsoft and Open-source are still far from each other : try to make a new build of your software for containers using Visual Studio : https://blogs.msdn.microsoft.com/jcorioland/2016/08/19/build-push-and-run-docker-images-with-visual-studio-teamservices/

I am quite certain that there are many articles, posts and even books already written on that subject. To be honest, I did not search for any of those. For some reason, I had to figure out sharding almost by myself building a customer design. So this post will just be my way of walking through the process, and confirm that I can explain it again. If someone finds this useful, I will be happy :) Here is the information I started with. We want to build an application that uses a database. In our case, we chose DocumentDB, but the technology itself is irrelevant. The pain point was that we wanted to be able to expand the application worldwide, but also to keep a single data set for all the users, wherever they were living, connecting from. That meant finding a way of having a local copy of the data, writable, in every location we needed. Having a readable replica of a database is quite standard. You may even be able to get multiple replicas of this kind. Having a writable replica is not very standard, and certainly not a simple operation to setup. Having multiple writable replicas… let’s say that even with reading the official guide from Microsoft (https://docs.microsoft.com/fr-fr/azure/cosmos-db/multi-region-writers) it took us a while to fully understand. As I said, we chose to use DocumentDB, which already provides the creation a readable replica with a few clicks. This is not enough, as we need to have a locally writable database. But we also need to be able to read data that is written from the other locations. What we can start with is to create a multiple ways replica set. We could have a writable database in our three locations, with a readable copy in each of the other two regions : Dessin ...