“Also, it is recommended to not deploy to all production environments in one go, exposing all the customers to the changes. A gradual rollout that exposes the changes to customers over a period, thereby implicitly validating the changes in production with a smaller set of customers at a time… As an example, for an application is deployed in 12 regions with US regions (4) having a high load, European regions (4) having a medium load and Asian regions (4) having a relatively lighter load, following would be the order of rollout.

“Also, it is recommended to not deploy to all production environments in one go, exposing all the customers to the changes. A gradual rollout that exposes the changes to customers over a period, thereby implicitly validating the changes in production with a smaller set of customers at a time… As an example, for an application is deployed in 12 regions with US regions (4) having a high load, European regions (4) having a medium load and Asian regions (4) having a relatively lighter load, following would be the order of rollout.

“Kubernetes was created to bring the idea of dynamic, container-centric, managed, scheduled-cluster thinking outside of Google… But what is a container and what does a containerized application mean in this context?” Original source: Kubernetes for the Kubernewbie - The Journey

“Kubernetes was created to bring the idea of dynamic, container-centric, managed, scheduled-cluster thinking outside of Google… But what is a container and what does a containerized application mean in this context?” Original source: Kubernetes for the Kubernewbie - The Journey

“On the business side, Progressive Delivery involves two core changes in the delivery model: Release progression – progressively increasing the number of users that are able to see (and are impacted by) new features (e.g. Stage 1: visible to developers only; Stage 2: visible to developers and beta users; Stage 3: visible to more users; Stage n: visible to everyone) Delegation – progressively delegating the control of the feature to the owner that is most closely responsible for the outcome.

“On the business side, Progressive Delivery involves two core changes in the delivery model: Release progression – progressively increasing the number of users that are able to see (and are impacted by) new features (e.g. Stage 1: visible to developers only; Stage 2: visible to developers and beta users; Stage 3: visible to more users; Stage n: visible to everyone) Delegation – progressively delegating the control of the feature to the owner that is most closely responsible for the outcome.

“Low-code [uses] declarative techniques instead of traditional lines of programming… Common features include reusable components, drag-and-drop tools, & process modeling. Individuals or small teams can experiment, prototype, & deliver apps in days or weeks.” Plus, marketsizing: something like $4bn. Original source: Why You Need To Know About Low-Code, Even If You’re Not Responsible For Software Delivery

“Low-code [uses] declarative techniques instead of traditional lines of programming… Common features include reusable components, drag-and-drop tools, & process modeling. Individuals or small teams can experiment, prototype, & deliver apps in days or weeks.” Plus, marketsizing: something like $4bn. Original source: Why You Need To Know About Low-Code, Even If You’re Not Responsible For Software Delivery

“Let’s think about control. I’d struggle to find any engineers operating within a DevOps mindset eschew control of their production systems. I encourage the use of a CMDB, but again, it’s live, automatically updated, and software-based. It’s called a Chef server. Similarly, ITIL places a strong emphasis on configuration. Teams I have built do the same. All changes to the system are made in code, go through a peer review process, are automatically tested, and rolled out in a recordable, repeatable, and auditable manner.

“Let’s think about control. I’d struggle to find any engineers operating within a DevOps mindset eschew control of their production systems. I encourage the use of a CMDB, but again, it’s live, automatically updated, and software-based. It’s called a Chef server. Similarly, ITIL places a strong emphasis on configuration. Teams I have built do the same. All changes to the system are made in code, go through a peer review process, are automatically tested, and rolled out in a recordable, repeatable, and auditable manner.