Launching a new business or project means that everything has to be built from the ground up, from defining services, functions, and product range, to deciding the technology, infrastructure, and resources required. Enterprises, to serve the evolving demands of customers and add business value, are looking to develop new applications faster with minimal resources and cost.

In greenfield development projects, the new applications built either solve unaddressed business challenges or entirely replace an existing inadequate system. Consider this example of a new start-up company that is going to launch an online, product range. The primary focus of the company is to build a minimal viable product (MVP) with the ability to make product improvements from customer responses. Without existing systems or architecture in place, the company plans to build a suite of applications to serve various business needs, add new functions, provide an uninterrupted online presence, and ensure scalability based on changing customer demands.

The company, with the absence of an existing legacy system, is weighing out the option of adopting microservices. If they choose microservices architecture, this would involve defining service boundaries (which need to be dynamic) and deciding the technology stack for each microservice. It would also include rethinking operations, creating a scaling strategy, provisioning infrastructure required for elastic scalability, and configuring and maintaining monitoring solutions.

While it is a relief not to inherit technical debt from legacy systems, there are many aspects to be considered when adopting microservices architecture for a greenfield development project.

Define your domain or service boundaries

When developing greenfield applications, defining service boundaries could be tricky. Before trying to categorize your system into different services, ensure you know your domain. For instance, you define that service A is responsible for doing a particular function. What if this changes or if you realize the function needs access to service B.

Before separating functions into microservices, you need to understand and have clarity about the dependencies they have. Only after some time would patterns emerge from which you can identify the functions and services and the problems they can solve. However, there would be apparent functions such as login or profile services that could be carved out into a microservice straight away.

Decide on the technology stack

The technology stack used with microservices in greenfield projects is diverse. You can combine multiple programming languages, frameworks, and data storage technologies. However, standardization becomes an issue with different teams using an entirely different technology stack. Low-code platforms offer one point of control for application updates and maintenance to overcome technology diversity. With a centralized repository for version control, multiple developers can collaborate and merge changes.

Achieve a minimum level of operational readiness

To start a greenfield project using microservices architecture requires a minimum level of operational readiness maturity. Operational readiness in terms of ensuring there is access to a deployment environment and building continuous delivery pipelines where services are created, tested and deployed. Whether it is identifying and provisioning infrastructure requirements, scaling strategy, or service discovery, you need to have a plan to address the operational complexities that could occur when adopting a microservices architecture.

Low-code platforms simplify application development, deployment, and delivery. They use Continuous Integration (CI) tools like Jenkins to provide a continuous delivery pipeline and provide an automated containerization workflow. Low-code platforms transform the way enterprise applications are developed and delivered.

Reorganize development, DevOps and IT teams

To ensure every microservice is managed independently, you would need to reorganize your teams and maintain a balance of resources. It is not productive to have engineers working on multiple microservices; neither is it feasible to have one person for each unique role. For instance, a DevOps engineer can manage dual roles of development and operations, or a full-stack developer can manage the entire application development lifecycle. Ideally, every team should have a balance of expertise which could comprise developers, testers, operations engineers, database administrators, UX designers, and in some instances, even product managers.

With the rapid increase in opportunities applications have to serve customer needs, development teams are under pressure to deliver at a fast pace with tight turnaround times. Added to that, the shortage of skilled professionals is hindering rapid application development. Here is where low-code platforms help by providing a user-friendly interface and a development environment where teams can collaborate on modules with efficiency.

Ensure microservices implementations do not turn into distributed monoliths

There are whispers about how most greenfield microservices implementations turn into "distributed monoliths." By taking a monolithic codebase and spreading it across a network, the benefits of microservices architecture fade. For instance, when making changes to business logic in a shared library, if you need to synchronize the deployments of multiple teams, it reflects the inability to deploy changes in isolation. When building a new system, it is a huge advantage to have a single, non-distributed codebase.

In greenfield, microservices-based implementations, low-code application development platforms provide business agility by automating systems and ensuring data security, integrity, and compliance with IT governance and standards. However, before going all in to adopt a microservices architecture, it would be useful to be clear about the fundamental aspects mentioned earlier about service boundaries, infrastructure, technology stack, resources, and team organization.

“Change before you have to.” This quote by Jack Welch, Former CEO, General Electric has never had greater significance than today. Everything is constantly changing, from the expectations of digital customers, the requirement for better user experiences by the next-gen workforce, changing business models according to business needs, to the modernization of technology, before it becomes inevitable.

Consider this example. A health-information and intelligence company in Stamford, Connecticut built a ‘health intelligence platform’ to create their labs’ competitive difference. The platform built years ago had advanced from enabling clients’ lab operations to creating an impact on lab research outcomes. While the software developed 2 decades ago was robust, there was an imminent need for modernization.

From the VP of tech engineering to the lab head, there were change agents or champions who recognized this need for modernization. However other stakeholders, comfortable using the old system, were apprehensive to move to new systems. In due course, the company embraced modernization and upgraded from a legacy, FoxPro-based Lab Information Management software (LIS) to a modern Java/Angular application.

By using a low-code platform, they were able to accelerate application development, automate ordered tests, simplify integration with external systems, and develop applications quickly and economically. This accelerated their time-to-market - a necessary competitive edge, where the extent of technology leverage could make the difference between invention and discovery. Taking this example, we will discuss the approach and the steps that every change agent should consider when embarking on the modernization journey.

Modernization is not only about scaling or ramping up software technology, it also requires an enterprise-wide change in mindset. A change in mindset in the way people work, collaborate and communicate with each other and with the technology they use. What most enterprises are facing today seems to be an impasse. On one hand, business owners feel that the use of technology is limited to the support they get from IT and on the other hand, there are tech owners who do not have the time or the skills to deliver more. When IT teams are overloaded with enterprise demands, the bandwidth for core business innovation is minimal.

For decades, enterprise-class systems have had a monolithic approach. Enterprise architecture has evolved from monolithic models to service-oriented architecture and is progressively moving towards microservices architecture. The role of enterprise architecture has also matured, from supporting IT to a strategic role of innovation.

Enterprises can stay competitive by incrementally transforming monolithic legacy systems to adopting a modern, agile approach such as microservices. Once they experience the agile delivery of microservices, innovation will naturally flow. Any change agent will tell you, undertaking an IT modernization initiative is not an easy feat and the first question that invariably arises is “how and where to start?”

Enterprise IT Modernization Using Microservices 

How and where to start 

In any migration or modernization project, making enterprise-wide changes all at once is not always feasible, as it would involve intense coordination and meticulous planning. Moreover, modernization requires investment in emerging technologies, therefore big budgets need to be approved and allocated. The first step in IT modernization is not to make a mountain of the existing monolithic system. If new functionalities need to be added to the software, adding them to the legacy system is only going to make the migration process more difficult. Instead, build independently deliverable services, microservices.

5 Aspects to Consider When Migrating to Microservices 

Here is an approach with 5 steps that every change agent in an enterprise should consider when they begin their journey of modernization to microservices.

• Integrate components and ensure data access by auto-generating APIs 

APIs are used to integrate components (third-party and internal) and the model used will determine the business profitability. Generating APIs for a new service or reusing code of existing services that invariably use legacy technology can be challenging. The pace at which APIs need to be generated is something most enterprises are grappling with.

In the earlier example, the health IT company had to build APIs over databases and custom services. Using a platform to integrate external EHR (electronic health record) systems and enable building a database of patient health records, a unified API helped them access data and run queries.

To improve productivity, low-code platforms are used to auto-generate APIs, where it is not limited to simple, database CRUD operations, but also the generation of APIs for search, filter, aggregate and export services, among others. APIs can be built over databases and for custom services and can also be generated for database queries with stored procedures. Using the ‘API designers’ feature in a low-code platform, REST APIs are generated automatically for every service imported into an application, be it a Database Service or Java Service.

Low-code platforms also offer the advantage of writing business logic by reusing generated APIs in popular languages like Java. When enterprises are in a position where they are still using legacy technology like JSF, Struts, JSP or Servlet where Java code is used, low-code makes it possible to extract the code and generate APIs from it. There are different ways in which a low-code platform can help in reusing code to generate APIs, either by obtaining the libraries of the code and wrapping it in a service or copying the code in a service. Moreover, since development teams would probably be using Java, reusing code and generating APIs becomes very easy.

• Expedite data migration, availability, and accessibility 

When it comes to migrating the most valuable asset, which is data, the challenge of “data gravity” arises. Over time, as data grows, how it attracts other data, how it is integrated and how it is customized, changes. Data migration not only has to be done with speed to avoid disruption, it also has to be done accurately and securely.

When migrating to microservices, all of the data from storage systems have to migrate from a monolithic solution. However, at the time of migration, the data itself is not accessible directly.

To make data available across microservices, frequent data migration routines or a synchronization process needs to be created and these datasets need to be made available as APIs. In the earlier example, daily schedules for data migration and syncing were created to ensure access to near real-time data and minimal process disruption for users.

There are several on-premise, open-source, and cloud-based data migration tools. From on-premise data migration tools such as Centerprise Data Integrator, IBM InfoSphere, Informatica PowerCenter, Microsoft SQL, Oracle Data Service Integrator and Talend, to open source tools like Apache NiFi, CloverETL, Myddleware, and Pentaho, to cloud-based tools such as Alooma, Fivetran, Matillion, Snaplogic, and Stitch Data. These tools can provide simple data migration and repeatability.

Low-code platforms simplify and accelerate the entire data migration process securely. They make it easy to integrate anything from databases to third-party libraries and deliver seamless experiences with offline data access and synchronization.

• Build simple UI applications that demonstrate immediate value 

Nothing compares to a user-friendly application to demonstrate its value. When using apps, the user interface (UI) is what delivers the experience for users. By creating ‘beautiful looking’ UIs, it is easier to get stakeholders to understand the value that an enterprise application can deliver.

Imagine you could provide users with better usability by providing a web application instead of a desktop application. What if you could create a modern UI that displays information and encourages interaction, something that was not possible until now. What if you can enable your users to use the functionality of modern applications through their mobile phones, on-the-go.

And what if you can build predictions and forecasts based on data and showcase it using powerful dashboards to stakeholders.

Modern, low-code tools have made it easy to create simple UI applications. With drag-and-drop features and limitless customization that low-code platforms offer, developers can create aesthetic UIs to deliver pixel-perfect application designs, at scale.

• Pull services out of a monolith - One at a time

When migrating to microservice architecture, the best way to start is to break down the monolith into manageable chunks. The best approach would be to pick microservices out of the existing monolith one service at a time. Once the first service is up and running out of the monolith, this will give insights into how to create more microservices.

• Identify the part of an application that can run independent of the monolith. Services such as reporting and dashboarding, or other such functionalities that can be made into independent microservices and which have frequent data sync available to migrate data to databases.
• Identify how to write back to the existing application. Many systems provide a way to write back to the existing system. Interfaces such as EDI messages, HL7/FHIR interfaces, and CSV files can be used to write back to monolith systems.

• Measure and show the value

Once a service is taken out of the monolith, identify more uses cases that can be pulled out of the existing application. Identifiable services could range from managing new customer orders, self-service applications providing customer information to a new payment service, basically, those services that can be managed as separate microservices.

The whole point of selecting one microservice at a time is to measure value and improvement. When choosing a service to be migrated or modernized, it is best to choose a high-value service, or a service that requires frequent change but not delivered as frequently, or one that can demonstrate visible visual improvement to stakeholders. Before creating a baseline to measure the effectiveness of change, make sure you gather relevant numbers such as the number of releases, amount of delivery and delivery time.

What microservices provide is a software component model that helps to future-proof systems against the changing business needs. Microservices works best when multiple teams are working in coordination to run a complex network of systems that require evolving applications. When applications and systems become complex and large enough to be broken down into separate services adopting microservices architecture is beneficial.

Make Migration to Microservices Meaningful

Inspire Innovation and Confront Change

Monolithic legacy systems cannot be transformed overnight. To migrate from monolithic systems and efficiently create enterprise-class microservices, a low-code approach has proven to be the most effective. Low-code platforms provide the ability to develop custom software stacks, deploy API-driven microservices-based applications and orchestrate IT infrastructure effectively. In this app economy, using an ‘API-first’ strategy with microservices architecture works great because it enables enterprises to focus on delivering value and accelerating innovation on a massive scale.

Look at microservices through a macro lens to understand how enterprises can use modern approaches such as low-code to rapidly respond to evolving demands. With composable architecture based on microservices, APIs, reusable components and containerization, low-code platforms empower enterprises to rapidly develop and deploy modern and cloud-native applications with agility, scalability, and simplicity.

Migration to modern technology is a major change for many enterprises, technologically and culturally. What low-code platforms provide is a catalyst that change agents can use to showcase the value of microservices to other stakeholders. Because modernization of legacy systems and migration to modern technologies is going to be inevitable, eventually.

Agility, scalability and stability, this is the essence of microservices architecture (MSA). For enterprises seeking scalability, for developers seeking application agility, and for change agents seeking support for digital transformation initiatives, MSA is a key enabler.

In the inevitable journey of modernization, what microservices architecture has provided is the agility and scalability needed to make continuous changes rapidly. When transforming monolithic systems, using microservices for one service at a time has made it possible to showcase the business benefits to a broader audience. MSA has proven to be a key enabler to pursue innovation and digital transformation initiatives.

Given the positive business impact, why are microservices positioned in the "trough of disillusionment" in the recently released Gartner Research on Hype Cycle for Application Architecture and Development, 2019? For one thing, because driven by the enthusiasm to adopt what's trending many have misinterpreted the essence of microservices which has eventually led to unsuccessful implementation.

To take microservices out of the "trough of disillusionment" and to not make the same mistakes made by other application leaders, consider the following aspects before you begin your journey of modernization.

Understand the essence before adopting microservices

The meaning of microservices has been mistaken by many application leaders. The essence of microservices revolves around continuous delivery, stability, and scalability. Applying the principles of service-oriented architecture (SOA), microservices emerge from domain-driven design (DDD) and DevOps. Each microservice is a loosely coupled yet independently scalable and deployable application service that has a single responsibility and focus on delivering one business task.

Any service smaller than monolithic systems does not make a microservice. What many consider microservices is in disguise "headless API SaaS" or pseudo-microservices. Several vendors also resort to "microservice washing" the services they offer. When building solutions, application leaders need to understand and clarify whether genuine microservices are considered and not versions of reusable or shared application components or a version of SOA.

Partition only relevant services

One of the benefits of microservices is agility. By partitioning every service as a microservice, the complexity increases and negates the benefits. Application leaders need to carefully decide which components can be put into services to ensure implementation is done in phases.

To get the most out of microservices, the multiple granularities of applications need to be identified. It would then be easier to decide which components can be partitioned as services. In this way, microservices can provide the granularity of services and the opportunity for better application development and release planning.

Consider the organizational and cultural changes required

Microservices architecture is complex and has disruptive organizational, technical and cultural impact. When the ownership of the entire lifecycle of an application or product is in the hands of developers, application leaders need to ensure the roles and responsibilities are defined and governance practices are established. The organization structure and cultural mindset have to be realigned to enable the successful adoption of this new approach to application development, deployment, and delivery.

Ensure teams are adequately trained

Microservices architecture is fast evolving and new patterns, design principles, concepts, and tools are introduced. With changes in the technology stack used, sharing of knowledge across teams must be encouraged. Developers, architects, and DevOps professionals need to be trained to use new software programs and application lifecycle management techniques. To empower development teams to innovate and deliver more, application leaders are using modern technologies such as low-code platforms to make full-stack development easier.

Improve agile development practices

The prerequisites of a microservices architecture are agile DevOps and continuous delivery practices. Before adopting microservices, enterprises must ensure they improve their agile development practices and methodologies. In digital transformation implementations, enterprise agility is a prerequisite. Rapid application development platforms are increasingly being used to improve agile practices because they leverage low-code technologies and use open standards-based technology stack to ensure digital transformation implementations are successful.

Application leaders need to first understand the essence, objectives, and applicability of microservices. Once this is clear, they need to implement microservices iteratively, one service at a time. One of the main reasons why microservices implementations fail is because application leaders have in the past adopted microservices without making changes (organizational, cultural, and technical). To transform enterprises and align them to the main goals of agility and scalability, change is inevitable. Successful microservices implementation requires commitment, discipline, in-depth understanding, and openness to venture into a steep learning curve. Application leaders need to use this formula and embrace change if they wish to move microservices out of the "trough of disillusionment".

As an application leader or change agent, we understand that an IT modernization initiative is not an easy feat. Continue reading to know how you can add the catalyst to change and to know how and where to start your journey of modernization when migrating from monolith to microservices architecture.

Good things come in small packages, and that's true of microservices. Read on to get a solid overview of the benefits this architectural pattern brings with it.

Traditionally, enterprises relied on a unified model for designing a software application. Here, key capabilities for managing input/output processing, error-handling, and UI are packaged into one monolithic process. In such a structure, all the application components are interconnected and interdependent.

Such a structure, however, limited the scope for an application to expand and scale. This is when microservices came into the picture. Here, a single monolithic system is broken down into a set of smaller services, carrying out a functionality in a distributed manner. Its loosely coupled structure enabled enterprises to add or iterate any component of an application independently. This gave scope for scaling and expansion at a much faster rate.

The Many Benefits of Microservices

• In this architecture, each service of an application runs in its own process and is independently deployable. If changes need to be made or new functionality needs to be added, a service can be pulled down, tweaked, and redeployed without affecting the application performance.
• Microservice-based design makes it easier to identify bugs and repair them. The problem can be contained to that particular service and then deployed once fixed.
• Microservices are language and technology agnostic. Each of the services can be developed using different programming languages and deployed in different environments. This makes the services flexible and can be scaled independently.
• As small services require smaller codebase, it makes maintenance easier and faster. Developing an application takes weeks not years as the code is organized around business capabilities.
• Another benefit of using microservices to modernize legacy applications is an increase in productivity for developers. In a modular architecture, small independent teams take ownership of their services and act within a well-defined context. This helps build a responsible and accountable DevOps culture.

Aiding Digital Transformation

Apart from providing agility to enterprises and making the architecture scalable, microservices enable DevOps automation with continuous delivery and deployment. This makes deployment processes swift and improves time to market. With continuous delivery, iterations can be carried out throughout the product lifecycle, resulting in better working software. Such flexibility is difficult to achieve with a monolithic architecture. More precisely, the very problem of cost and time can be overcome with microservices.

Taking a cue from this, Amazon migrated to microservices. In 2001, the Amazon retail website was developed based on a monolithic architecture. This slowed down development cycles and restricted their ability to innovate. Once they adopted the modular design, it dramatically improved their front-end development lifecycle. Thanks to a microservices continuous delivery process, Amazon can now make 50 million deployments a year.

It’s the same story with Walmart, where they could not handle 6 million page views per minute with their aging monolithic architecture. After embracing microservices in 2012, Walmart experienced 20-50% cost savings and conversions went up by 20% overnight.

It Is Not a Silver Bullet

With that said, it is not that microservices are without any drawbacks. Although breaking down an application into smaller components have its advantages, it also distributes the complexity of maintaining them. Things can get more complicated with multiple databases and transactions. To make it uncomplicated, microservices architecture relies on APIs to deliver services. APIs bring in the standardization of interfaces in the development process. Structured APIs behave in a manner that is bound to remain unaffected by the technology used underneath. While developing applications, developers can work on coding the core functionality of the application. Other third-party services provided by the application can be called through APIs, thereby reducing the development time.

In a microservices-based architecture, multiple micro apps interact with each other using APIs. The benefit of such a structure is that, if need be, only a part of the application can be scaled by adding more hardware resources. Unlike in a monolithic app structure, where the entire app has to be scaled.

With the increasing popularity of cloud computing, containerization, and APIs, microservices are becoming more reliable. This trend in code management and deployment is enabling companies to respond to shifting customer demands in a swift and agile manner. But, as with any modern technology, a genuine requirement needs to be identified first to reap its benefits.

Update: This blog post was also published in DZone.com

Enterprise application delivery is evolving day by day and enterprises have discovered that traditional development methods do not address the needs of modern business. Many leaders continue to be in denial about the power of digital trends that are radically transforming the business landscape. But in the world of adapt or perish, enterprises have to make changes and take steps towards transforming their architecture to create provisions for future trends in application delivery.

The new normal

Let's take a look at six trends that have urged enterprises to take action. Each of these trends is not an independent phenomenon but a group of closely related phenomena that not only influence but also act as a catalyst for the others.

1. Mobility: In the last few years, not only have the number of mobile devices surpassed PCs, but users now turn to their mobile devices first. Ever since mobile apps entered the enterprise scene, they have ushered in new forms of collaboration, communication, and business efficiencies. The number of devices managed in the enterprise increased 72% from 2014 to 2015 and now, 3+ devices are used daily by an employee for work activities. With the diversity of screens and form factors exploding, enterprise mobility has become the key strategy for every business to empower and manage employee mobility in order to meet security, agility, and productivity demands.
   

2. Consumerization: The distinction between expectations for consumer and enterprise applications has rapidly narrowed due to the impact of consumer-originated technologies on enterprises. 90% of enterprises say that the use of a consumer or individual services used for work is pervasive today including Dropbox, Google, Skype, Linked In, Facebook, and other social networking sites. 49% of these sites are used with IT approval, and 41% are not. To achieve the greatest user adoption and long-term success, there is a conscious effort to move away from a purely utilitarian approach to one that strives to deliver an experience for that meets the same standards evident in consumer products.

3. Containerization: Perhaps the biggest story in the development and DevOps circles over the past couple of years has been the explosion of containers, with Docker driving the path toward developer and enterprise adoption. Docker’s express growth is already revolutionizing continuous delivery. The influence of containers continues to grow and it is beginning to move beyond mere optimization to transformation on the way IT builds and delivers applications. Several enterprises are looking at containers as an alternative to virtualization and cloud computing, at least for the need of long-tail business applications.

4. API Growth: With the dawn of cloud computing and the proliferation of apps, companies are exchanging data and services at an ever-growing rate. APIs can increase agility by de-coupling and exposing business processes. The past few years, however, have seen such explosive growth that the API space is evolving more rapidly than ever before. In 2015, as many as 40 APIs were being added per week to the Programmable Web directory, and the total number of APIs stood at around 15,000. The key thing to consider here is that these numbers are based on publicly available APIs and do not reflect any private or internal API growth at all, of which some estimate may even outnumber the public total. The future RESTful APIs will not only drive the exchange of data but also influence enterprise architecture.

5. Data Deluge: The amount of data being generated globally is growing at a rate of 40% per year. Add to that the complexity of an ever-connect world of the Internet of Things. Forecasts indicate that there will be 20.8 billion connected things (IoT) by 2020. As enterprises capture more data from more sources, they are bound to experience greater growth rates for both structured and unstructured data. Since data forms the crux of business applications, enterprises will have to prepare to manage data integration from disparate internal and external systems.

6. Microservices: Microservices are small, single-purpose applications that collaborate using APIs to deliver services. Even though microservices have been used for a while, the increasing popularity of cloud computing, containerization, and APIs have made microservices more reliable. In many organizations, developers are already employing microservices architecture whether management knows it or not. Early signs indicate this approach to code management and deployment is helping companies become more responsive to shifting customer demands. Microservices is poised to take the scalability and continuous delivery to the next level in the years to come

It is time to face this new dynamic and begin to plan for your organization’s digital transformation. You need a fresh perspective to give you and your team a powerful voice in setting business direction. In the age of the customer, tech
professionals must work with business executives to use technology to drive growth and delight customers. 

I would be glad to understand how your organization is planning to deal with these trends. Also, please add to these trends if you feel that I have missed out on anything.

Organizations across the globe rely on WaveMaker to navigate the new normal use. Our Rapid Application Development or RAD Platform is the most open, extensible, and flexible low-code platform that complements your existing enterprise application delivery. You can get started with a free, 30-day on-premise or online trial.