Microservices Architecture - Cloud Native Apps

Editor's Notes

• #14: Source: MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/ Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer http://en.wikipedia.org/wiki/Command–query_separation https://skillsmatter.com/courses/345-greg-youngs-cqrs-domain-events-event-sourcing-and-how-to-apply-ddd
• #19: DevOpsAmazon: https://www.youtube.com/watch?v=mBU3AJ3j1rg NetFlix: https://www.youtube.com/watch?v=UTKIT6STSVM DevOps and SRE: https://www.youtube.com/watch?v=uTEL8Ff1Zvk SLI, SLO, SLA : https://www.youtube.com/watch?v=tEylFyxbDLE DevOps and SRE : Risks and Budgets : https://www.youtube.com/watch?v=y2ILKr8kCJU
• #26: https://dzone.com/articles/microservices-vs-soa-2
• #27: https://dzone.com/articles/microservices-vs-soa-2
• #28: e
• #40: https://www.forrester.com/report/Application+Modernization+Service+By+Microservice/-/E-RES122550 https://www.forrester.com/report/Microservices+And+External+APIs+Underpin+Digital+Business/-/E-RES137951 https://www.gartner.com/smarterwithgartner/4-steps-to-design-microservices-for-agile-architecture/ https://www.gartner.com/doc/3898774/succeed-microservices-architecture-using-devops e(l(44)/3) = 3.5
• #44: Analytics = Score = 3 + 5 + 3 = 11 WS = 1.05 + 1.25 + 1.2 = 3.50 Shopping Cart Score = 5 + 3 + 3 = 11 WS = 1.75 + 0.75 + 1.2 = 3.70 Customer Score = 3 + 3 + 1 = 7 WS = 1.05 + 0.75 + 0.40 = 2.20 Catalogue Score = 3 + 3 + 5 = 11 WS = 1.05 + 0.75 + 2 = 4.80 Order Score = 7 + 3 + 5 = 15 WS = 2.45 + 0.75 + 2 = 5.20 Inventory Score = 7 + 5 + 3 = 15 WS = 2.45 +
• #48: Memory You can limit the amount of RAM and swap space that can be used by a group of processes.It accounts for the memory used by the processes for their private use (their Resident Set Size, or RSS), but also for the memory used for caching purposes. This is actually quite powerful, because traditional tools (ps, analysis of /proc, etc.) have no way to find out the cache memory usage incurred by specific processes. This can make a big difference, for instance, with databases. A database will typically use very little memory for its processes (unless you do complex queries, but let’s pretend you don’t!), but can be a huge consumer of cache memory: after all, to perform optimally, your whole database (or at least, your “active set” of data that you refer to the most often) should fit into memory. Limiting the memory available to the processes inside a cgroup is as easy as echo1000000000 > /cgroup/polkadot/memory.limit_in_bytes (it will be rounded to a page size). To check the current usage for a cgroup, inspect the pseudo-filememory.usage_in_bytes in the cgroup directory. You can gather very detailed (and very useful) information into memory.stat; the data contained in this file could justify a whole blog post by itself! CPU You might already be familiar with scheduler priorities, and with the nice and renice commands. Once again, control groups will let you define the amount of CPU, that should be shared by a group of processes, instead of a single one. You can give each cgroup a relative number of CPU shares, and the kernel will make sure that each group of process gets access to the CPU in proportion of the number of shares you gave it. Setting the number of shares is as simple as echo 250 > /cgroup/polkadot/cpu.shares. Remember that those shares are just relative numbers: if you multiply everyone’s share by 10, the end result will be exactly the same. This control group also gives statistics incpu.stat. CPU sets This is different from the cpu controller.In systems with multiple CPUs (i.e., the vast majority of servers, desktop & laptop computers, and even phones today!), the cpuset control group lets you define which processes can use which CPU. This can be useful to reserve a full CPU to a given process or group of processes. Those processes will receive a fixed amount of CPU cycles, and they might also run faster because there will be less thrashing at the level of the CPU cache. On systems with Non Uniform Memory Access (NUMA), the memory is split in multiple banks, and each bank is tied to a specific CPU (or set of CPUs); so binding a process (or group of processes) to a specific CPU (or a specific group of CPUs) can also reduce the overhead happening when a process is scheduled to run on a CPU, but accessing RAM tied to another CPU. Block I/O The blkio controller gives a lot of information about the disk accesses (technically, block devices requests) performed by a group of processes. This is very useful, because I/O resources are much harder to share than CPU or RAM. A system has a given, known, and fixed amount of RAM. It has a fixed number of CPU cycles every second – and even on systems where the number of CPU cycles can change (tickless systems, or virtual machines), it is not an issue, because the kernel will slice the CPU time in shares of e.g. 1 millisecond, and there is a given, known, and fixed number of milliseconds every second (doh!). I/O bandwidth, however, is quite unpredictable. Or rather, as we will see, it is predictable, but the prediction isn’t very useful. A hard disk with a 10ms average seek time will be able to do about 100 requests of 4 KB per second; but if the requests are sequential, typical desktop hard drives can easily sustain 80 MB/s transfer rates – which means 20000 requests of 4 kB per second. The average throughput (measured in IOPS, I/O Operations Per Second) will be somewhere between those two extremes. But as soon as some application performs a task requiring a lot of scattered, random I/O operations, the performance will drop – dramatically. The system does give you some guaranteed performance, but this guaranteed performance is so low, that it doesn’t help much (that’s exactly the problem of AWS EBS, by the way). It’s like a highway with an anti-traffic jam system that would guarantee that you can always go above a given speed, except that this speed is 5 mph. Not very helpful, is it? That’s why SSD storage is becoming increasingly popular. SSD has virtually no seek time, and can therefore sustain random I/O as fast as sequential I/O. The available throughput is therefore predictably good, under any given load. Actually, there are some workloads that can cause problems; for instance, if you continuously write and rewrite a whole disk, you will find that the performance will drop dramatically. This is because read and write operations are fast, but erase, which must be performed at some point before write, is slow. This won’t be a problem in most situations. An example use-case which could exhibit the issue would be to use SSD to do catch-up TV for 100 HD channels simultaneously: the disk will sustain the write throughput until it has written every block once; then it will need to erase, and performance will drop below acceptable levels.) To get back to the topic – what’s the purpose of the blkio controller in a PaaS environment like dotCloud? The blkio controller metrics will help detecting applications that are putting an excessive strain on the I/O subsystem. Then, the controller lets you set limits, which can be expressed in number of operations and/or bytes per second. It also allows for different limits for read and write operations. It allows to set some safeguard limits (to make sure that a single app won’t significantly degrade performance for everyone). Furthermore, once a I/O-hungry app has been identified, its quota can be adapted to reduce impact on other apps. more The pid namespace This is probably the most useful for basic isolation. Each pid namespace has its own process numbering. Different pid namespaces form a hierarchy: the kernel keeps track of which namespace created which other. A “parent” namespace can see its children namespaces, and it can affect them (for instance, with signals); but a child namespace cannot do anything to its parent namespace. As a consequence: each pid namespace has its own “PID 1” init-like process; processes living in a namespace cannot affect processes living in parent or sibling namespaces with system calls like kill or ptrace, since process ids are meaningful only inside a given namespace; if a pseudo-filesystem like proc is mounted by a process within a pid namespace, it will only show the processes belonging to the namespace; since the numbering is different in each namespace, it means that a process in a child namespace will have multiple PIDs: one in its own namespace, and a different PID in its parent namespace. The last item means that from the top-level pid namespace, you will be able to see all processes running in all namespaces, but with different PIDs. Of course, a process can have more than 2 PIDs if there are more than two levels of hierarchy in the namespaces. The net namespace With the pid namespace, you can start processes in multiple isolated environments (let’s bite the bullet and call them “containers” once and for all). But if you want to run e.g. a different Apache in each container, you will have a problem: there can be only one process listening to port 80/tcp at a time. You could configure your instances of Apache to listen on different ports… or you could use the net namespace. As its name implies, the net namespace is about networking. Each different net namespace can have different network interfaces. Even lo, the loopback interface supporting 127.0.0.1, will be different in each different net namespace. It is possible to create pairs of special interfaces, which will appear in two different net namespaces, and allow a net namespace to talk to the outside world. A typical container will have its own loopback interface (lo), as well as one end of such a special interface, generally named eth0. The other end of the special interface will be in the “original” namespace, and will bear a poetic name like veth42xyz0. It is then possible to put those special interfaces together within an Ethernet bridge (to achieve switching between containers), or route packets between them, etc. (If you are familiar with the Xen networking model, this is probably no news to you!) Note that each net namespace has its own meaning for INADDR_ANY, a.k.a. 0.0.0.0; so when your Apache process binds to *:80 within its namespace, it will only receive connections directed to the IP addresses and interfaces of its namespace – thus allowing you, at the end of the day, to run multiple Apache instances, with their default configuration listening on port 80. In case you were wondering: each net namespace has its own routing table, but also its own iptables chains and rules. The ipc namespace This one won’t appeal a lot to you; unless you passed your UNIX 101 a long time ago, when they still taught about IPC (InterProcess Communication)! IPC provides semaphores, message queues, and shared memory segments. While still supported by virtually all UNIX flavors, those features are considered by many people as obsolete, and superseded by POSIX semaphores, POSIX message queues, and mmap. Nonetheless, some programs – including PostgreSQL – still use IPC. What’s the connection with namespaces? Well, each IPC resources are accessed through a unique 32-bits ID. IPC implement permissions on resources, but nonetheless, one application could be surprised if it failed to access a given resource because it has already been claimed by another process in a different container. Introduce the ipc namespace: processes within a given ipc namespace cannot access (or even see at all) IPC resources living in other ipc namespaces. And now you can safely run a PostgreSQL instance in each container without fearing IPC key collisions! The mnt namespace You might already be familiar with chroot, a mechanism allowing to sandbox a process (and its children) within a given directory. The mnt namespace takes that concept one step further. As its name implies, the mnt namespace deals with mountpoints. Processes living in different mnt namespaces can see different sets of mounted filesystems – and different root directories. If a filesystem is mounted in a mnt namespace, it will be accessible only to those processes within that namespace; it will remain invisible for processes in other namespaces. At first, it sounds useful, since it allows to sandbox each container within its own directory, hiding other containers. At a second glance, is it really that useful? After all, if each container is chroot‘ed in a different directory, container C1 won’t be able to access or see the filesystem of container C2, right? Well, that’s right, but there are side effects. Inspecting /proc/mounts in a container will show the mountpoints of all containers. Also, those mountpoints will be relative to the original namespace, which can give some hints about the layout of your system – and maybe confuse some applications which would rely on the paths in /proc/mounts. The mnt namespace makes the situation much cleaner, allowing each container to have its own mountpoints, and see only those mountpoints, with their path correctly translated to the actual root of the namespace. The uts namespace Finally, the uts namespace deals with one little detail: the hostname that will be “seen” by a group of processes. Each uts namespace will hold a different hostname, and changing the hostname (through the sethostname system call) will only change it for processes running in the same namespace.
• #54: Unique IP Address of the Pod: https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/
• #55: https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/
• #63: https://www.netdevconf.org/2.1/slides/apr6/zhou-netdev-xdp-2017.pdf
• #72: The index file is made up of 8 byte entries, 4 bytes to store the offset relative to the base offset and 4 bytes to store the position. The offset is relative to the base offset so that only 4 bytes is needed to store the offset. For example: let’s say the base offset is 10000000000000000000, rather than having to store subsequent offsets 10000000000000000001 and 10000000000000000002 they are just 1 and 2. Kafka wraps compressed messages together Producers sending compressed messages will compress the batch together and send it as the payload of a wrapped message. And as before, the data on disk is exactly the same as what the broker receives from the producer over the network and sends to its consumers. https://thehoard.blog/how-kafkas-storage-internals-work-3a29b02e026
• #74: Durability - the ability to withstand wear, pressure, or damage.
• #76: https://docs.confluent.io/current/kafka/deployment.html
• #77: https://docs.confluent.io/current/kafka/deployment.html
• #110: http://martinfowler.com/bliki/DDD_Aggregate.html Effective Aggregate Design By Vaughn Vernon Part 1 : http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf Part 2 : http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_2.pdf Part 3 : http://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_3.pdf Video Part 2 : https://vimeo.com/33708293
• #111: References https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/microservice-ddd-cqrs-patterns/domain-events-design-implementation
• #114: http://www.javaworld.com/article/2078042/java-app-dev/domain-driven-design-with-java-ee-6.html
• #120: https://martinfowler.com/bliki/BusinessCapabilityCentric.html
• #123: Source: MSDN – Microsoft https://msdn.microsoft.com/en-us/library/dn568103.aspx Martin Fowler : CQRS – http://martinfowler.com/bliki/CQRS.html Udi Dahan : CQRS – http://www.udidahan.com/2009/12/09/clarified-cqrs/ Greg Young : CQRS - https://www.youtube.com/watch?v=JHGkaShoyNs Bertrand Meyer – CQS - http://en.wikipedia.org/wiki/Bertrand_Meyer http://en.wikipedia.org/wiki/Command–query_separation https://skillsmatter.com/courses/345-greg-youngs-cqrs-domain-events-event-sourcing-and-how-to-apply-ddd
• #140: Pat Helland (Amazon) : Life beyond distributed transactions… http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf
• #141: http://www.infoq.com/articles/ebay-scalability-best-practices
• #144: In computer science, an invariant is a condition that can be relied upon to be true during execution of a program, or during some portion of it. It is a logical assertion that is held to always be true during a certain phase of execution
• #181: https://stackify.com/site-reliability-engineering/ https://www.tutorialspoint.com/itil/terminologies.htm
• #183: Lean Thinking – Increased Capacity to Innovate : A-B Testing https://stackify.com/site-reliability-engineering/
• #191: https://stackify.com/site-reliability-engineering/
• #192: https://stackify.com/site-reliability-engineering/
• #193: DevOpsAmazon: https://www.youtube.com/watch?v=mBU3AJ3j1rg NetFlix: https://www.youtube.com/watch?v=UTKIT6STSVM DevOps and SRE: https://www.youtube.com/watch?v=uTEL8Ff1Zvk SLI, SLO, SLA : https://www.youtube.com/watch?v=tEylFyxbDLE DevOps and SRE : Risks and Budgets : https://www.youtube.com/watch?v=y2ILKr8kCJU