BT

InfoQ Homepage Articles Software Architecture and Design InfoQ Trends Report—April 2020

Software Architecture and Design InfoQ Trends Report—April 2020

Bookmarks

Key Takeaways

  • New software architecture trends to watch include micro frontends, Data Mesh, AsyncAPI, and Policy as Code. The variety of purposes shows that innovation is occurring in many different areas in the architectural landscape.
  • As microservices are becoming more common, there is more resistance to starting with a microservices architecture. More companies are looking at the fundamentals of correctly built distributed systems or creating modern, modular monoliths, with the idea that they may need to be broken into microservices at a later date.
  • GraphQL has clearly crossed the chasm, with the only debate being how widely it is adopted. There is still innovation regarding scaling GraphQL and making it ubiquitous and general-purpose for large enterprises.
  • There has been increased interest in low-code/no-code platforms, which can empower non-developers to customize a system. 
  • Several architectural concepts that are tracked are only applicable to certain situations. Therefore, they do not have a natural progression across the adoption curve. Examples include functional programming and event-driven architecture.

The goal of good software architecture is to help manage complex systems. In response to distributed systems, event-driven architectures, and big data, the latest innovations in software architecture hope to harness the best practices that are emerging, and also help guide engineers away from common pitfalls.

The InfoQ Software Architecture and Design Topic Graph highlights major software architecture concepts and their current state of adoption in the industry. InfoQ and QCon both focus on the left side of the chart, covering the state of software trends among Innovators and Early Adopters. We also look for ideas that will eventually "cross the chasm" and be adopted by a majority of companies.

The editors at InfoQ who cover Software Architecture and Design (A&D) regularly discuss the state of the topic graph, identifying any new trends we should be covering, and noting any significant changes in adoption of items already on the graph. This article provides some of the highlights from our internal discussion, adding necessary commentary to the simple text shown on the topic graph.

Contributors to this discussion included:

In the past year, we have seen notable ideas showing up across the A&D landscape, each addressing a different set of software trends. For example, as microservices become more widely adopted, and practitioners find more benefits and drawbacks, patterns emerge to reinforce what has worked well and make the next generation of microservices more successful.

Innovators

Four new trends among innovators include micro frontends, AsyncAPI, Data Mesh, and Policy as Code.

Micro frontends

Micro frontends are intended to bring the same benefits of microservices to the UI layer. By breaking up a complex system into smaller, more manageable pieces,teams can rapidly develop and release new features and functionality.

After appearing on the InfoQ Podcast, we reached out to Luca Mezzalira, author of Building Micro Frontends for his thoughts on what we can expect in the next year or two.

Luca Mezzalira: Micro frontends are not a new trend but they gained traction in 2019.

There are still a lot of best practices to discover and the community is very vibrant. In the past 8-10 months we produced new frameworks, techniques and documentation for making micro frontends more approachable for all developers.

I don’t think micro frontends will be the silver bullet for frontend development, however I truly believe it’s a wonderful addition to Single-Page Applications and Server-Side Rendering architectures.

Micro frontends shine when we have projects with tens of developers working together in a large business domain and we want to reduce the complexity by dividing into multiple subdomains, independently deploy different parts of the applications without creating communication and coordination overhead across teams.

Several organizations started to embrace them and in 2020 I expect to see many more case studies explaining how these companies adopt the paradigm and which PROs and CONs they have encountered.

I believe in 2020, micro frontends will become an established architecture and understood by the frontend community, I don’t expect micro frontends will ever be used for all the frontend projects but there are many companies who can really benefit from this architecture paradigm.

AsyncAPI

AsyncAPI addresses the incongruity between restful APIs and event-driven architectures and event sourcing. The increased adoption of microservices has led to more companies implementing EDAs, which has led to advancements around EDAs. However, those improvements require moving from synchronous, request/response APIs to something purpose-built for async communication.

Daniel Bryant said he’s "anecdotally hearing about this in customer chats. Nearly everyone with strong Swagger/OpenAPI adoption is looking at something like AsyncAPI."

Data Mesh

The concept of a data mesh was first discussed in an article by Zhamak Dehghani of ThoughtWorks. The thought-provoking concept is that the pitfalls of a traditional data warehouse or a monolithic data lake can be avoided by embracing domain-oriented data ownership.

Thomas Betts said, "We haven’t tracked data architectures in the past, but I am interested to see if this follows the trends of breaking monoliths into microservices for increased agility in big data systems."

InfoQ asked Dehghani for her thoughts on the current and future state of Data Mesh.

Zhamak Dehghani: Connected decentralization is an underlying trend in the evolution of our digital economy, society, and organizations. Over the last decade, technologies such as cloud, microservices, APIs, containerization, and domain-driven design have enabled the decentralization of the operational world. But, unfortunately, the world of data has been dominated by the anachronistic paradigm of centralization. Data mesh is a direct response to the analytical data management failure modes, and is aimed to leapfrog organizations in becoming data-driven, aligned with the connected decentralization trend.

In the next year or two, I expect to see a wider adoption of Data Mesh and more implementation case studies being shared. I expect many early implementations will be creating custom engineering tooling and technology, which I hope would lead to a proliferation of open source tooling or extension of cloud providers’ products to meet the technical needs of Data Mesh.

I see the industry’s question of What is Data Mesh, is changing to How to do Data Mesh in the new year, and of course How to do Data Mesh Right in the following years as the adoption grows.

Given Data Mesh requires an organizational change around data ownership and governance, engineering-oriented organizations who have strong support from executives and leadership can truly materialize this paradigm.

Policy as Code

We are also seeing innovation around managing the software development lifecycle. Policy as Code is one of the notable trends that help put structure around the desired system state. This builds upon the idea of infrastructure as code, and brings similar benefits to the architecture level. Bryant saw Policy as Code talked about at KubeCon and by cloud vendors.

Early Adopters

Serverless

One subject that always sparks a healthy discussion is serverless. The InfoQ editors feel serverless has not yet crossed the chasm, and there has also been some pushback against the idea. This is related to the pushback against microservices, as more teams are realizing that serverless and microservices architectures are not intended to be the correct solution to every problem.

This has led to a healthy discussion about correctly built distributed systems and modular monoliths.

Jan Stenberg observed serverless and distributed systems being discussed at the recent DDD Europe conference:

Stenberg: An interesting point for me is that Gojko Adzic talked about serverless and was very enthusiastic but pointed out that even a very simple "Hello World" application is highly distributed. This will require skilled developers; will this affect the cost effectiveness of serverless?

Vladik Khononov recommended reading Composite/Structured Design, written in the 1970’s by Glenford J. Myers for everyone interested in microservices. He said that although the book doesn’t mention the term microservices, the underlying design principles discussed in the book are the same as for microservices.

Stenberg also thought Modular Monoliths should be added to Early Adopters:

Stenberg: With a reference to Kamil Grzybek, Randy Shoup and others, but also to Stefan Tilkov who back in 2015 claimed it’s very hard to build a modular monolith and therefore recommended going for microservices if needed.

But this is kind of strange. How can building a well-designed modular application be Early Adopter? Is there something like "new generation" Early Adopter?

Humble: With serverless, I don’t think it has crossed the chasm and I’m actually seeing some anecdotal pushback against it. I think this falls into a wider pushback against microservices (or, more accurately, people realizing that microservices are not the answer to every problem) — we had a talk on the topic at QCon London. I think it may well stay something of a niche approach. Do we think we should be tracking/talking about the return of the monolith?

Bryant: I did initially wonder if "serverless" had crossed the chasm, but I don’t think it has. There are a bunch of reports (for example) indicating large growth opportunities in this space, which also makes me think it’s still in Early Adopter.

Betts: A year ago, people were talking about building systems that were entirely serverless, and that hype has diminished. Individual serverless features, such as AWS Lambda or Azure Functions, may have crossed the chasm, but completely serverless architecture has not, and possibly won’t ever achieve majority adoption.

Low-Code and No-Code

Low-code and no-code solutions promise to put more capabilities into the hands of end users, and not require developer involvement. While industry veterans may be skeptical of what seems like a vendor push, there has been a clear rise of developer experimentation using these platforms.

Humble: I’m something of a cynic on low-code platforms; I think this is mainly a vendor push and one I’ve seen before. That said I would expect to see more developers experimenting with low-code platforms — partly fueled by a renewed push from Microsoft for its PowerApps, Flow, Power BI, and Power Platform products. I also found it interesting to see Google acquiring AppSheet. These platforms are becoming big business and I think it is a trend we should be keeping an eye on.

Betts: (Lightweight) workflow and decision automation platforms should remain in Early Adopter. This has a strong correlation to low-code/no-code platforms, which may be a better catch-all term for the topic graph. These platforms target non-developers, and as such, are on the buy instead of build end of the spectrum. The challenge is around integration, rather than building major systems on top of one platform.

Stenberg: Low code reminds me of my younger colleagues, who at the university in the 90’s were only taught 4GL because OO was obsolete.

I don’t see modern workflow engines, (like Zebee) belonging to low code, (but maybe they belong to "workflow and decision automation platforms"). They are handling core business workflows where you want a domain to know that your core business is running smoothly, and you don’t want to discover problems through monitoring.

GraphQL

GraphQL has very clearly crossed the chasm, but the question among InfoQ editors is whether it belongs in the Early or Late Majority. While the use of GraphQL as a technology may have reached the Late Majority, we are still seeing innovation where GraphQL is influencing architectural decisions around scalability and creating a cohesive language across a system.

Humble: I think GraphQL is firmly across the chasm. Dylan has it at Late Majority in the latest web trends report.

Betts: I think GraphQL has crossed the chasm. The level of adoption has taken it from something just implemented at the API layer to a central aspect of how a system is designed. This is probably most analogous to TypeScript’s adoption, where teams recognize the benefits of strongly-typed constructs throughout the system.

Ethics in Software Architecture

Bryant raised the question of whether we should track ethics in this queue. "I’m increasingly seeing ethics sessions and tracks at SACON and QCon." We ultimately decided not to include ethics on this topic graph as it is better represented on the Software Culture & Methods Topic Graph.

Humble noted how QCon and InfoQ have been discussing ethics for several years:

Humble: I think we’ve tended to treat ethics as a culture topic but it is something that cuts across queues. We should absolutely continue to track this and report on it. I’m proud that we were quick off the marks to cover it with the ethics track at QCon London and the corresponding eMag, and I think it’s very important that we continue to talk about it given how pervasive software is in everybody’s lives.

Betts saw ethics as an aspect of the Architect as Technical Leader:

Betts: While I applaud increased awareness and discussion around ethics, I’m not sure ethics needs to be called out on the A&D topic graph. However, I do think there are many aspects of ethics that must be considered by technical leaders, and I would like to see some InfoQ articles about ethical considerations in A&D. I always believe the best people to provide guidance in this area are the practitioners who truly understand it. Without proactive leadership, designs end up being reactive and forced to comply with inevitable government regulations, such as GDPR and CCPA.

Other Topics

The remainder of the chart is mostly unchanged. Reactive programming, HTTP/2, and gRPC have crossed the chasm, but all other items have not moved. This is to be expected for A&D, where good ideas take longer to mature and have a longer lifetime compared to programming language trends.

For reference, the topic graph from early 2019 is shown below. The 2020 version is at the top of the article.

About the Authors

Thomas Betts is the Lead Editor for Architecture and Design at InfoQ, and a Principal Software Engineer at IHS Markit Technology, now a part of Informa Tech. For over two decades, his focus has always been on providing software solutions that delight his customers. He has worked in a variety of industries, including retail, finance, health care, defense and travel. Thomas lives in Denver with his wife and son, and they love hiking and otherwise exploring beautiful Colorado.

Charles Humble took over as editor-in-chief at InfoQ.com in March 2014, guiding our content creation including news, articles, books, video presentations and interviews. Prior to taking on the full-time role at InfoQ, Charles led our Java coverage, and was CTO for PRPi Consulting, a renumeration research firm that was acquired by PwC in July 2012. For PRPi he had overall responsibility for the development of all the custom software used within the company. He has worked in enterprise software for around 20 years as a developer, architect and development manager. In his spare time he writes music as 1/3 of London-based ambient techno group Twofish, whose debut album came out in February 2014 after 14 years of messing about with expensive toys, and spends as much time as he can with his wife and young family.

Daniel Bryant works as a Product Architect at Datawire, and is the News Manager at InfoQ, and Chair for QCon London. His current technical expertise focuses on ‘DevOps’ tooling, cloud/container platforms and microservice implementations. Daniel is a leader within the London Java Community (LJC), contributes to several open source projects, writes for well-known technical websites such as InfoQ, O'Reilly, and DZone, and regularly presents at international conferences such as QCon, JavaOne, and Devoxx.

Jan Stenberg is working as an IT consultant since more than 25 years in northern Sweden, experienced in building systems on both .Net/C# and JVM/Java platforms. His experiences range from large distributed and service based systems through web based and rich client applications down to hardware related software.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Mistake

    by Ilnur Gabdushev /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    > Humble: ... Amazon acquiring AppSheet

    it was Google, not Amazon

  • Re: Mistake

    by Charles Humble /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thank you for pointing this out. I’ve corrected the text.

  • "The goal of good software architecture is to help manage complex systems."

    by Mark Paauwe /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "The goal of good software architecture is to help manage complex systems."
    At Dragon1 (the SaaS platform and open method for Visual Enterprise Architecture) we interview our customer very often. We have a base of over 3000 organizations in 110 countries world wide making use of us.

    By the way: A software architecture is an aspect view of a system. It is the coherent set of software concepts and their principles (working mechanisms of concepts) with the intent to increase the quality (like strength, adaptivity and usability) of (software) systems.

    When we ask CIOs, IT Managers and architects about the goal of good software architecture they not all say it is to help manage complex systems. They are very much more specific.

    The top three answers to such a question we get is this:
    1) To be able to build solutions (or complex systems) that do the work for us (workflow, RPA)
    2) To make sure we can integrate and connect everything (interoperability)
    3) To make sure that our IT Infrastructure will develop / converge to a future state that will support/execute our strategy better than the current state.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.