How can software be made flexible in continuous delivery?

In my view, there is no huge difference between DevOps CI/CD vs Modular design. When you built a software for a specific requirement, it could be a combination of multiple programming languages, tools and techniques. So, as long as you don’t have dependencies on each, modular design is best approach to deliver in parallel but please make a note that collection of different software modules is a software product. It means, decentralise during modular design but centralise when you use it as a whole.

Implementing these practices requires a cultural shift within the organization, emphasizing agility, collaboration, and a willingness to embrace change. It is not just about tools & processes; it's also about the mindset & practices that enable teams to deliver quality software quickly & reliably. Infrastructure as Code (IaC): Manage infrastructure using code, which allows for repeatable and consistent deployment of environments. Tools like Terraform or AWS CloudFormation can be used for this purpose. Monitoring and Logging: Implement comprehensive monitoring and logging to quickly identify and address issues in production. Real-time monitoring tools can provide insights into application performance and help in proactive issue resolution.

Modular design is undoubtedly beneficial for flexible development. However, the correct modularization of a system largely depends on the architects' level of knowledge about the business's functionalities. With a deeper understanding, the chances of achieving a more accurate abstraction of behavior increase. Therefore, it is essential to carry out thorough work of understanding and comprehension before defining the responsibilities and interfaces of each module.

In today's fast pace society, adopting a modular design pattern for software development is absolutely essential for speed, flexibility, agility and economies of scale. As in, any well thought out business function or application will evolve over time... which is why most monolithic designs will eventually fail. Having a modular design allows for the adoption of other support mechanisms like micro-services architecture (interchangeable components) with secure API end points for asynchronous communications, Agile methodologies, containerization and a DevOps platform (automated delivery pipelines) to provide continuous integration (CI) and continuous delivery (CD) to drive consistently, reliability and cost optimization.

There is no Continuous Delivery possible without modular design. However we should be clear that modular design doesn't guarantee CD. If individual components are not having well defined API/Data contracts then CD is typically not possible as change to one component will have ripple effect of causing regression in other components. A well thought through versioning and backward compatibility scheme in API/Data contracts has to be implemented to achieve full CD in modular architecture.

Dynamic configuration can be quite useful which allows the properties of application to be changed without any downtime. The application parameters can be modified using API based configuration.

Below are few points that can aid in seamless continuous delivery of software - Modularity and design of a well defined interface of software modules would play a vital role here. A loosely defined interface of software modules would reduce the cohesiveness and thereby enabling parallel development and delivery. - Language-neutral and platform-neutral designs (e.g. protobuf) and other microservices best practices enables new feature deployment which in-turn would reduce hiccups in continuous delivery of software. - Well defined software which can accommodate space for continuous improvement based on business inputs, feedback or adhering to recent engineering best practices is another key area to lookout in your software.

Handling software configuration enable it to run with different releases of its own modules. Eventually certain modules can be promoted to production while others may require further testing. Handling each module version and being able to choose a release to run will give you flexibility to be business driven.

In my experience, configuration module is a must module within proper SW architecture design. The main benefits are: 1) Better and flexible SW version control. 2) Flexible collaboration between the teams members and between different teams. 3) Flexible business logic control. 4) Automated builds to provide better stable and consistence SW version. It will also lead for better automated deployment process. 5) Better code review abilities for better code review processes and better code integration

In the light of this consideration, I totally affirm the significance of configuration management into the continuous delivery. Successful deployment and operational of software require consistency and reliability in their behavior across various environments or platforms. It is essential to note that configuration management makes it possible for the software to adopt and change its behavior as necessitated by the varying nature of the environments within which it operates. For that being said, Organisations must be able to make sure that the system works well within every setting without demanding alteration of the code.

Store configuration settings outside of the codebase, making it easier to modify settings without changing the code. This is particularly important when deploying the same codebase in different environments. Use feature toggles to enable or disable certain features at runtime. This allows for easy experimentation and can facilitate phased rollouts of new functionality.

On similar lines.. Consider adopting A/B testing frameworks to release new features to a smaller set of consumers/customers.. gradually "dialling up" if results are positive. Having a well defined dial-up (and dial-down) plan helps manage risk of degrading production services while setting stakeholders expectations around timelines.

La conmutación de estado, apagado o encendido de funcionalidades, es práctico para algunas funcionalidades que fueron completadas y se liberan a la espera de que otra parte se libere, como por ejemplo el servicio que consume datos y el servicio que los provee aún no esta listo, una vez que la contraparte se libera, encendemos la nueva funcionalidad para que pueda operar. La conmutación de estado es práctico para el desarrollo, no necesitas esperar a que todos los componentes estén listos para poder liberar el tuyo y promueve la entrega temprana. Por otro lado, proceso de entrega de software se basa en la entrega de valor, lo que se traduce en funcionalidades 100% operativas para el cliente basadas en los criterios de aceptación.

It's important to risk assess and place conditions and limits around which features should be designated toggable. In enterprise or medical software for example, releasing partially completed elements could adversely impact health outcomes, profits and other business metrics. A thorough risk and impact assessment should be carried out on any proposed togglable features ahead of any experiments and toggle testing.

To allow controlled release, feature toggles are a must. Especially when delivering to the cloud, a big bang approach (release for all users at once) will at a certain time bite you. Having mechanisms in place to control release of certain features and more importantly be able to revoke them will make you a reliable and trustworthy service provider. Often the awareness to introduce feature toggles is there, but not much is spent on how to manage them...

It's clear that having smaller, independent chunks of software can potentially enable faster delivery while reducing the chance of negative scenarios, thanks to fault isolation. However, it's common to encounter some side effects when teams use microservices: code duplications, complexity in management and monitoring etc. But the benefits for business are significant: if you can deliver faster, you can get feedback faster, you can adopt faster - you can win a market faster.

From my experience, as long as we create a development and deployment pipeline that allows for frequent, reliable, and automated releases while maintaining software quality and stability, is a good approach to go. Simplifying software itself is a different ball game like adopting Micro-services architecture and deploy services on docket containers.

My immediate reaction was to caution on the use of Microservices. Then I read what the others have already written. And to my pleasant surprise they basically think the same. There is a place for Microservices, but they do increase complexity on many levels. So if your organization has problems to deliver software fast enough, chances are that Microservices will make your problems a lot bigger rather than smaller. A good approach is to look at things from the business domain. What granularity of services makes sense there? In other words: Use what works and not what is fashionable today. It is interesting that the inventor of the term Microservices actually recommends a well-designed, modular monolith architecture as a default approach.

In my experience - microservices help achieve better scale by giving flexibility to scale different parts independently. However adopting Microservices doesn't necessarily mean CD or faster deployment. On the contrary - I have seen poorly designed microservices (without well defined API contracts and backward compatibility considerations) leading to slow down in deployment pipelines.

Many comments here are refer to the concern coming from microservices solution, there might be complexity and duplication of code. Regarding the duplication code in microservices I would like to suggest points to be consider in order to reduce the duplicarion. I will refer to 2 points. API Gateway: Using API gateway to centralize common functionalities such as authentication, request validation, and response formatting. Microservices can focus on their core business logic, while the API gateway handles cross-functionality. Event-Driven Architecture: Event-driven architecture can help in decoupling services and allows for the reuse of events and event-handling logic across different microservices.

While it's important to have feedback from stakeholders, no one knows the software better than the technical team. Therefore, a culture of excellence should be fostered, and a technical backlog should be maintained. As corrections are made and the software matures, adjustments should be made to elevate it to a level of abstraction and reusability, making it truly flexible as new requirements emerge.

It’s quite common get feedbacks from all fronts at once and it will become a challenge to get it all organized as a backlog or parking lot of your product requirements. Be sure to catalog everything you receive from users, management or other stakeholder and run a backlog review session from time to time to prioritize what item is more important first so you don’t break the value delivery chain for the business.

Totally agree considering to implement robust monitoring and logging solutions to gain insights into the behavior of the system in real-time. This helps in quickly identifying and addressing issues that may arise from new deployments, and also keep documentation up-to-date, providing clear guidelines for developers, operators, and other stakeholders. This ensures that everyone involved understands the system's architecture and deployment processes.

Analytics should be considered as an option for collection continuous feedback. Some benefits of using analytics to feedback on user activity, is that it's non intrusive and doesn't require the filling and collecting of forms. User journeys, preferred routes, occurrences can all be captured in the background, and reports produced from which insights can be gleaned.

One of the things I found most helpful is aligning expectations with the customers. When the feedback or response to what the customer described and asked for will occurs in meaningful milestones, rather than a quick fixes in temporary versions.

I like to see every new feature release as an "experiment". This experiment is coded, tested and then made available to a small set of consumers first. If there are no issues found, then we gradually increase the traffic exposure. If issues are observed them we dial-down to zero (not roll back the deployment) and fixes are added.. whole process is repeated again. Key thing is to keep the experiment duration short and automate dial-up/dial-down process as much as possible. Adding human review is not necessary - but sometimes needed when metrics are giving conflicting results. Needless to say - this requires investment in building right instrumentation (metrics) and monitoring to "observe" how experiment is doing.

Do not forget about three pilars of instrumentation: logging, observability and metrics. Most of teams do have (better or worse) logging, some have metrics too. But metrics only will tell you that your CPU is busy, not what it is doing. Adding observability to the mix will give you tons of insight into how your software is performing - and will allow troubleshooting at the speed of the light.

Continuous delivery needs to be a win-win for the provider as well as customer. One of the best ways to such a win-win formula is described in the form of a framework called 3 Layer Product Model suggested by Jan Bosch. In this model we have a foundation layer where we have all proven stuff, a differentiation layer where we provide market differentiation and an experimentation layer which helps us perform experiments or pilots. This lens can be applied also for team composition. As each experiment matures to a feature we can promote that to a differentiation layer and once it becomes basic part of solution can be promoted to foundation. This will enable system to evolve like an organism.

Don't forget that there is a lot of auxiliary automation needed to facilitate continuous delivery. This does not come for free, and automating everything is usually not cost effective. Make sure you understand what to automate first, and how this impacts the bottom line.

The biggest challenge I have experienced that I haven’t seen discussed is database/data model updates. This is a very complex problem to manage, and a variety of the techniques described in this article would likely be employed in conjunction with one another to address a database schema change. Even a “nosql” database might have some data complexity that needs to be accounted for during a transition period. “Dual data model” capability is something that needs to be coded into the application, feature flagged, and then cleaned up post data model update.