SATURN 2020

When you design a system for the cloud there are certain characteristics that are important. Some of these characteristics are there from day one and some are added because of experiences encountered over time. Managing a live system sometimes leads to architectural decisions that are there to not only protect customers but to also protect the developers that work on these systems. Microservices-based architectures are great when your system is deployed on the cloud for a bunch of reasons. But what happens when you need to move your cloud-based architecture to an on-prem system? Platforms such as OpenShift are making the transition easier, but there are major differences that architects need to consider. The architecture constraint differences alone are enough to give a systems architect the shivers.

In this presentation we will talk about our experiences moving a cloud-based architecture on Kubernetes to an on-prem solution on OpenShift. We will talk about the differences in architecture constraints, quality attributes, and the developer experience. We'll also talk about the challenges we faced and things we didn't get right.

By the end of the presentation, you will have the knowledge necessary to understand the architectural differences between on-prem and cloud-based systems and the effort required to transition from one to the other. You will also have the knowledge necessary to understand how to build the right way for a hybrid cloud world.

By the end of this session you will also be able to understand the following:

• What architectural considerations to think about when moving a product from cloud to on-prem - or vice-versa
• How to think about reusability when designing systems to enable yourself for moving to a different architecture
• How to mitigate risk when designing features, for future use
• Knowing what it takes to do this kind of work
• What the differences are in API design when transitioning to a new platform, and a new user persona focus

The dynamic development of Cloud Computing with the introduction of novel Cloud computing models like serverless creates new challenges for Cloud deployment. This presentation describes how to implement Multi-Cloud native strategies using advanced an open source framework that allows for Cloud-agnostic Multi-Cloud deployment and optimized management of the serverless applications based on flexible monitoring, context-aware maximization of the application owner’s utility of the deployed serverless components, and autonomic reconfiguration based on the application’s current execution context.

All stages of the cloud deployment planning and designing process will be shown. Also, the key execution steps will be provided.
The design and architecture details decisions will be presented along with additional sources of information (detailed design is published as paper on Tools50+1 conference). Also, the use case applications will be briefly presented with the benefits of using MELODIC platform.

Event-Driven Architecture (EDA) has quickly become a topic that is on the tip of the tongue of many technology professionals. With the popularization of architectural styles, such as microservices, EDA has emerged as a necessary pattern for loose coupling and increased scalability. Implementing EDA through a large, costly, big-bang approach is not the only way. EDA can be implemented through an iterative approach leveraged to drive implementation, while providing the flexibility to evolve over the life of the program. This presentation will offer a unique take on the experience of implementing changes through an EDA approach—directly from the perspective of someone in the trenches. It will identify how this approach is critical to the success of the overall solution for the multi-year program’s goal to create a new claims management system. This presentation will focus on two specific areas: how to capture events from a legacy system, and how to leverage those events as a pattern of integration for building modern business processes. It will provide an overview of the journey through transforming an aging, database-centric application to an event-based system with the ability to respond to changing business demand. It will also discuss EDA patterns such as publish/subscribe, event notification, and event-carried state transfer, which are key building blocks in defining a new ecosystem.

Application migration is the process of moving an application from the existing operating environment to a new one. Application migration is a complicated process because the new environment can be substantially different from the old one. The important part of this process is moving application data and relevant application logic while delivering the key application capabilities without any sacrifice to their service levels and taking advantages on the capabilities of a new platform. The migration is usually driven by a strong operational need to add features, add scale, or improve performance that would be difficult to achieve in the existing environment. If we are dealing with a legacy application, it is often the case that some of its parts, modules, data or capabilities are no longer useful and should be retired. At the same time, application parts still could be retained and migrated if they are needed to support the application’s functionality and can operate in the new environment.

Despite providing multiple benefits, moving legacy applications to Microservices Architecture (MSA) poses its own set of additional challenges due to the distributed nature of MSA applications. It requires not only re-architecting the legacy applications, which are usually monolithic applications, as a set of loosely coupled service, but also changing and building infrastructure and tools to manage, monitor, and test microservices. Substantial changes also need to be made in the software development process and the organization of development teams to adopt and advance adoption of DevSecOps practices. If the organization doesn’t have these practices in place, it needs to start following them and making organization and process changes on the early stages of migration.
There are two well-known approaches for breaking a monolithic application into modules or microservices:
• by application capabilities
• by application data or bounded context

Both of these approaches have a few challenges. It is possible to identify application capabilities; however, the capabilities might have inter-dependencies and it might be hard to untangle them in a legacy application. Splitting a legacy application by data domains requires conducting a full analysis, if not a full reconstruction, of an application domain model. In that model some of the data components might be outdated or irrelevant. As a result, it might be hard to decide if they need to be transferred to a new platform or not.

In this presentation, we propose a new approach to split monolithic legacy applications to modules or microservices for purposes of migrating to a new platform. We propose using mission threads as a tool for the analysis of an existing application capabilities and defining how these capabilities will be moved to a new platform.

As developers, we understand that our purpose is to deliver value to the business, ; what often eludes us is how to understand the business and where we can be of most value. Domain Driven Design (DDD) and Enterprise Architecture are two different attempts at getting to this understanding.

Enterprise Architecture has the possibility to guide the development of our big enterprise software portfolio in the right direction. Connecting the existing IT portfolio to the business functions and using this as a map to guide future development.

Enterprise Architecture (at least the way we employ it) is an exercise in understanding how the business functions are organized (business capabilities), what information the business is working with, and what IT applications are used to support this.

Domain Driven Design employs Strategic Design as a way to analyze the business domain and organize it into different context to provide some guidance on how to organize the software under development.

We have in the last few years seen a kind of resurgence in the use of Domain Driven Design in relations with to how you should design your microservice architectures. There has have been, and still isare, a lot of discussions around the link between the strategic design promoted by DDD, in particular the Bounded Contexts, and Microservices.

The central idea in this talk is to show how the Business Capability model from Enterprise architecture is closely related to the Bounded contexts Contexts of DDD and thus to Microservices.

In this 45-minute technical talk, I will introduce the information technology-process assessment standard (ISO/IEC 15504) and the Automotive SPICE Process Reference Model to the audience. I will discuss how the architecturally significant requirements and quality attributes fit into the reference model and the benefits of conformance for software architects. In addition, I will provide examples of the difference between architecture design, intent, and process compliance.

Are you about as fed up as I am with all the hype surrounding microservices? Are you tired of being told how your “two pizza team” is supposed to build a “microservice” over a “bounded context” using “ubiquitous language”? Who even talks like that?

I say we come together, expose some of the hype and dogma surrounding microservices, and lay waste to all this craziness.

You don’t have to go all in to use containers. You’re not going to get arrested by the “12 Factor Police” if you don’t include a connection string in an environment variable. You aren’t Netflix, and you shouldn’t act like Netflix.

This talk is not only fun, but by the end you’ll feel encouraged, justified, and ready to use technology to YOUR advantage. Let’s get ready to rant.

This talk will cover several topics relevant to mobile computing in disadvantaged environments, including disaster areas and the tactical edge. The focus will be on using a microservice-based architecture to best provide capability to users in these environments. We will start by exploring the specific challenges that disadvantaged environments pose to effective computing, which include network, computational, and power limitations.

Next, we will discuss the architectural approaches that address these challenges. We will start by suggesting what we consider to be the most important quality attributes that a software solution should support in order to best provide capability to the user, given the environmental limitations. This may include (but is not limited to) attributes such as Survivability, Resiliency, Scalability, Adaptability, Security, and Performance.

Finally, we will examine how a microservices approach can support the desired architectural quality attributes, drawing on our experience with various projects in this domain. Several approaches, technologies, and hardware platforms will be examined as exemplars, including a variety of microservice management and orchestration approaches.

This session introduces the concepts of building microservices, problems associated with building such applications and some solutions. We also discuss an example of a complete end-to-end web applications using Java and Jakarta as a backend, Angular as frontend, and with NoSql or SQL as data store (aka JAQ Stack). We will also discuss the concept building web applications using tech stacks instead of frameworks.


The theme of the presentation is divided into 4 sections as listed below:

1. What - Overview of microservices architectures
2. Why/Problems - Architecture of a web application
3. How/Solutions
- How to use existing technologies as stacks instead of new frameworks to build web applications
- Code demo of an example implementation using Java, Jakarta, Angular, and MongoDB (aka JAQ Stack)
- Overview of how to manage DevOps
4. Next steps

As the development of modern web applications is becoming more sophisticated and challenging, developers often have trouble identifying the core platform and building on top of it. While using Java as the primary technology to render a web application, extending/integrating it with some of the latest JavaScript technologies is a big hassle. And there are more trends with teams and enterprises using more of JavaScript frameworks, especially Angular to build the UI and UX of web applications.

Coming from a Java developer’s perspective, bringing in an application, for example built with Angular, into a Java based web application and deploying it together is a very time-consuming process and there are no standard procedures or technologies that enable them to do it. A quick example of this are applications built on Java-based CMSs (like Adobe Experience Manager); the web applications need to be deployed as a single jar package with the UI embedded into the jar.

JAQ Stack fills in this gap and simplifies the process for developers to build a complete web application using Angular as frontend, Java as backend, and with capability to connect to any database. All of this without the need to learn any new technology or a framework. Applications with JAQ Stack can be built as (A) Monoliths - where the application stack comes with pre-built maven profiles and examples projects that enable developers to bring in an Angular application into a Java EE based web application to build a single deployable War/Jar file. This helps DevOps to manage the entire application as one deployment, as in most standard monoliths; and (B) MicroServices - where the application can be built as microservices with the frontend and backend deployed as separate entities and communicating with each other using standard RESTful architectures.

First conceived by John Kindervag in 2010, zero-trust security is a network architecture that verifies both identity and devices before they can access another system. Traditionally, users or devices would connect first, then get vetted—zero-trust flips that around.

Zero-trust security principals are now being adopted as a requirement by a growing number of organizations due to an increase in security breaches. As such, software architects should familiarize themselves with zero-trust and, where appropriate, start applying it. While the zero-trust concepts have been around for a decade, just recently techniques emerged to make a zero-trust approach practical for all organizations.

When applied correctly, zero-trust permits a strong security posture to be attained without a negative impact on ilities, as is often the case when securing systems. This presentation covers the history, benefits, and details about where to apply these principles. The speaker will also introduce a few options for building in zero-trust while presenting a high-level architecture of a system developed with his leadership. As part of this, we will discuss examples of how ilities were positively impacted—such as agility improvements from better being able to leverage infrastructure-as-code when deploying throughout the release pipeline.

Coming soon!

Equinor has been an active participant and believer in the open source space with many open source projects, one even included in the Debian Linux distribution. But we are going further: Our strategy is that all source code we develop shall be open unless there is a clear reason to keep it closed.

I will explain how a large company like Equinor can do this, and why we think it is so important, how other actors in our industry, especially in the United States, seem reluctant to follow, and how we think open source will shape our industry going forward.

I will talk about what open source software is, what it isn't, why we think it is important, and why other large enterprise organizations should open up and contribute to the open source ecosystem.

Augmented and virtual reality devices have become widely used for training across many industries, especially in training the execution and observation of step-by-step processes. However, the development of such applications can be a costly undertaking when starting from scratch. Common pitfalls can be avoided, and common assets can be leveraged when building off of a foundation instead.

This presentation will detail my team’s vision to architect and implement a generalized, customizable framework that leverages the software product line concept. This framework will support rapid development of training applications for various immersive devices and will address common quality attributes at the foundation level, to be used by many teams across and potentially beyond Sandia National Laboratories.

*Sandia National Laboratories is a multimission laboratory managed and operated by National Technology and Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525. SAND2020-0760 A*

Traditionally, architects decide on the architecture and conformance of solutions to enterprise architecture. Projects often start with a comprehensive architecture document, but a transparent evaluation of the value to the customer is rarely done. This dynamic has shifted in the digital era. Most organizations now apply agile approaches in translating user requirements into working software.

The focus in agile teams is often on the frequent delivery of working software to enable the business to adapt quickly to changes in its environment. Although this is a principle of agile, it could also create architectural deficiencies and increased technical debt.

In this talk, I will present the challenges of architecting in an agile environment, showing the role of the architect as an agilist, futurist, and catalyst. I will also provide practical approaches that can be applied immediately to your agile environment.

In this talk, I’ll interleave quotes from Ward Cunningham with the historical context he was in, including IT development practices, programming languages, object-oriented programming, and typical software development processes. I’ll propose a definition for ur-TechDebt that is limited in scope compared to typical tech debt definitions.

I’ll cover questions like these:
-What percent of ur-TechDebt can we expect to find using a tool?
-How does ur-TechDebt relate to domain-driven design and design patterns?
-What causes ur-TechDebt?
-Does refactoring fix all ur-TechDebt?