– The road towards microservices –
The SmartCLIDE consortium pursues the design and development of a Cloud IDE that offers full support to the services creation life cycle: from specification of user stories to deployment in the cloud. Having performed a retrospective look to software development approaches, the consortium aims to employ a low-code software development paradigm for creating reusable and easily deployable microservices that can be indexed and composed in more complex business processes, in an online development platform that will be comprehensible for business stakeholders with limited technical skills. Artificial Intelligence methods will further assist the proposed Development Environment by providing smart auto-complete and service discovery features.
Before digging into the details of the solution, let’s explore the history of software development to better understand the rationale and the problems that SmartClide solves. Since the waterfall model was described in the early ’70s, introducing a set of consecutive or linear steps for developing software (system and software requirements, analysis, design, coding, testing, and operations), several development paradigms have been described over the last 50 years. Primary evolution of waterfall was the V-life cycle, adopted by highly regulated sectors since it included a quality assurance layer that described a reverse waterfall process for verification and validation activities. When waterfall models were applied incrementally, we talked about incremental models. These models, though still linear, show the need to obtain an early functionality provision to obtain feedback and, therefore, try to reduce risk. For example, the Spiral Model added a risk analysis phase in each iteration. As another alternative to the rigid waterfall model, Rapid Application Development was proposed to deal with the flexibility of software development but required regular access to users. The Rational Unified Process (RUP) was the obtained result of a work that started looking into why software projects had failed and it went back to the spiral model. RUP divided the development process into four distinct phases each one involving business modelling, requirements, analysis and design, implementation, testing and deployment.
Agile + DevOps
However, despite all these attempts for more efficient software project management, until the late 90s many software projects of various sizes evolved into enormous disasters with huge budgets and time outruns. The need for a new paradigm as a response to waterfall models led to The Manifesto for Agile Software Development. It was a turning point in software development which brought together several of the values and principles already seen. The four values upon which the manifesto was signed are: (a) individuals and interactions over processes and tools; (b) working software over comprehensive documentation; (c) customer collaboration over contract negotiation; and (d) responding to change over following a plan.
In the agile way of work, software projects should be delivered incrementally, piece by piece where each piece is a fully functional unit of software. Software is being developed by small, robust, and self-organized teams which respond quickly and interact efficiently with the external environment. This is a smart way of working but requires a re-organization of many aspects of the software development lifecycle, infrastructure and deployment operations being one of them. If the team needs to build and deploy frequently and quickly every new functional software unit it needs to be able to do it with minimum interactions and communication overhead with other teams that are classically involved in these actions (network, database, infrastructure, middleware). This challenge led to the rise of a new area, the DevOps (Development Operations).
Since the first time the software business heard of DevOps in 2008, it has evolved really fast turning the buzzword into a reality that is transforming digital business all over the world. The philosophy behind DevOps aims at demolishing the walls that create operational silos in business, development and operations/infrastructures creating an environment where valuable work continuously flows, there is a continuous feedback up and downstream, and continuous improvement is a common practice. Among many other practices, the full autonomy and end-to-end responsibility of software development teams can be considered the cornerstone of DevOps. These practices mean that software creation teams will have the full responsibility to take an application to production: from the specification of requirements/user-stories to its deployment in a server. SmartCLIDE focuses on DevOps organizations offering assistance at all the stages of the software creation life cycle, namely: specification and planning, creation, verification, packaging, release, configuration and monitoring. The main practices that back autonomy and responsibility are the creation of multidisciplinary teams (including staff with business and operations knowledge), continuous communication, an extreme automatization of processes and the existence of a solid common knowledge base.
Microservices
Apart from the software operations area, Agile paradigm also transformed the software architecture scenery with the introduction of microservices. That’s because small, self-managed teams are more likely to develop small or medium-sized, autonomous, self-contained software modules which need a common execution platform along with rules for inter-module communication. This describes the microservices paradigm. A microservices architecture is a development methodology wherein you can fragment a single application into a series of smaller services. Microservices are developed around business capabilities, and as such are independently deployable with automated deployment mechanisms. Related DevOps technologies can be used to help these automations. Each microservice is executing in its own process and interacting with lightweight mechanisms with other microservices or applications. This isolation and independence results in minimal management of these services, which are usually being built in different programming languages and employ different data storage technologies according to each element requirement. Below, we discuss the main features and benefits brought by microservice architectures.
Dynamic Scalability. Based on the development of small isolated components, developer teams can easily scale up or down based on the requirements of a specific element. The flexibility of microservices lets a system expand fast without requiring a significant increase in resources. A monolithic architecture would require scaling the whole application. Each module in microservices can scale independently through: (a) X-axis scaling, by cloning with more memory or CPU; and (b) Z-axis scaling, by size using shading.
Technology Flexibility. This refers to the microservice architecture flexibility on its technology stack that leads to eliminating the constraints of vendor or technology lock-in and platform dependency. Each microservice can be built up using the software stack required for the specific element. Language, framework, data sources or any other dependencies required can be provided from a container without affecting the whole application design or the communication between the microservices in the ecosystem.
Easier and shorter development cycles. These are achieved through the important feature of agility that further leads to productivity and speed, smaller project development, ease of building and maintaining apps, that are independently DURS (deployed, updated, replaced & scaled). Since each microservice is a separate project, professionals can get involved in the process more easily because they do not have to study the system as a whole and they can work only on their part. Decomposing the monolithic structure into separate services, leads to team decomposition into more small engineering teams that work independently which increases agility. The modern Agile approach is tightly connected with practices as DevOps concepts, continuous integration (CI), and continuous deployment (CD). All of these practices allow for faster deployment, problem-solving, and time to market. This type of agility when combined with CI / CD tools, like Jenkins, and their underlying pipeline configuration capabilities, results in faster and smaller project development life cycle procedures. Compared to a microservices architecture, a monolithic architecture hampers the Agile and DevOps processes because of its tight connections between each and every component.
Fault Isolation. Small isolated microservices are less likely to affect the overall ecosystem when failing. A monolithic architecture is rigid when it comes to replacing functionalities or making changes. Small changes in one place can cause ripple effects, bugs and errors in the entire system due to the extreme coupling. As such microservices architecture improves replaceability and upgradeability of the system.
Reduced Downtime / Quick Response-time. Developers and DevOps could use another service when components fail, and the application continues its work independently. With the use of related technologies that provide virtual servers, containers, pods and clustering this architecture offer reduced response downtime.
The next part will present “Quality and security in a microservices world“
The reader can find more details on this topic in the public deliverable D1.1-State-of-the-Art and Market Requirements.
No responses yet