DEV Community: Anas Khattar

Organizing AWS Community MENA GameTech Day 2021

Anas Khattar — Thu, 01 Jul 2021 17:44:13 +0000

After launching me-south-1 during AWS Summit Bahrain 2019 we got to meet the amazing Pakiza Abdulrahman from EDB Bahrain, who explained how the game development community is growing in Bahrain and how the launching of the new AWS Region in Bahrain will decrease the latency for gaming development and game streaming in the region.

UNESCO sees digital games as innovative tools for teaching and learning about peace and sustainability.

Last year 2020 we only managed to run the AWS MENA Community Day and this year we decided on a virtual GameTech Day conference to start with and shed the light on a world of opportunity in the game development industry especially with cloud scalability and agility as game development have an interwoven demand within all other digital experiences.

We were lucky to be AWSomely sponsored by AMD who are interested to shed light on their AWS general purpose and game development and streaming instance offerings.

Community, Outreach and Communication

For collaboration and outreach we talked to Arabic Games organizer Joseph Azzam and the UnReal Bahrain community lead by Yousef BuHaza to help us navigate the regional game development ecosystem because they have alot of experience with Game Jams in the region.

Our AWS Communities in MENA were very excited and curious at the same time since its a new topic for most digital businesses in the region. A meetup will be created within all participating user groups. You can find a list of AWS user groups in MENA here.

Speakers

The speakers come from around the globe and from the MENA region to bring new perspectives, technologies and skills to our audience. Here's a list of our speakers, topics and their short bio.

Musab Abdullah - Empowering Bahrain and the MENA Tech Community

Musab is the Executive Director of Investment Development at the Bahrain Economic Development Board (EDB). In his capacity, he focuses on international outreach and attracting investments to the Kingdom within the ever-growing technology sector. Along with continuous policy advocacy and eco-system building to ensure ease of investment and continuous growth and success for investors.
Musab and his team work closely with technology-related companies, including startups, that are looking to access the region through the Kingdom of Bahrain. This includes supporting the companies throughout the decision-making process, through to their establishment and potential expansion of their operations. Musab is also responsible for working with key stakeholders to identify the strategic direction of the sector, develop the eco-system and ensure that Bahrain offers an attractive, seamless and friendly business environment for all entities, from startups to corporates.
Prior to joining the EDB, Musab worked in the telecommunications sector for over a decade, as a policy-maker with the Ministry of Transportation and Telecommunications and as a regulator with the Telecommunications Regulatory Authority. His work focused on ensuring the continued growth and development of the sector, through introducing forward-looking policies, rolling out national projects and representing the Kingdom in international forums such as the International Telecommunications Union. He has also worked with a number of entities in other fields, including e-Government projects with the Central Informatics Organisation (now the Information and eGovernment Authority) and on banking solutions with Kuwait Finance House.

Musab holds a BSc. in Computer Science from the University of Bahrain and an MSc. in Finance from DePaul University.

Linkedin - Web

Michael DeNeffe - AMD and AWS – Powering Game Development

For my entire career I’ve paired a passion for technology with an intuition for business and market development—resulting in a blend of business strategy and non-traditional ideas. Cloud graphics represent the perfect technology and marketplace to exercise my passion and experience

I've developed partnerships big and small, all with the end goal to drive business success. I’ve managed dozens of product launches from cloud to enterprise to consumer and gaming. In the process I’ve driven success for companies, from start-ups to industry leaders.

Linkedin

David Heidt - Go global in minutes: How you can accelerate your gameservers and backends with AWS Edge Services.

AWS Senior Solutions Architect for Gaming, get in touch with David on his social channels.

Linkedin - Twitter

Olivier Chappe - The anatomy of a Presence API: how to modernize application with AWS Serverless services.

AWS GameTech Solutions Architect, get in touch with Olivier on his social media channels.

Linkedin - Twitter

Marion Finnigan - Know your Players, grow your Game: A Guide to LiveOps in the Cloud

15 years in tech, covering the full breadth (hardware, operating systems, software, cloud), has led me to my happy place - the games industry. I worked with customers up and down the value chain, ranging from retailers (B2C), ISPs and telcos (B2B2C) to now video games developers/publishers and cloud providers (B2B). I'm an experienced and determined all-rounder with strong business acumen, an analytical and structured approach, and obsession for my customers - all influenced by strong values that I live by:

Say what’s right and act upon it.
Always do the best you can and be humble about it.
Be passionate about what you do.
Treat others as you wish to be treated.

https://www.linkedin.com/in/marionfinnigan-love-what-i-do/

Joseph Azzam - Unreal Engine and the Epic Ecosystem

As part of the Evangelist team at Epic games, Joseph travels mostly in the Middle East to talk and teach Unreal Engine.
Joseph founded LebGameDev, a non-profit initiative that focuses on growing the gamedev scene in Lebanon.
He specialized in a wide range of topics including VR, cultural heritage preservation, photogrammetry, tech art, and Blueprint, which he used to Develop Byblos VR.
He is currently teaching game development Saint-Joseph University of Beirut.

Linkedin - Twitter

Yousef BuHaza - The Impact of GameTech Across Sectors

Unreal Bahrain is a community-based group of volunteers that supports innovators and entertainment entrepreneurs in Bahrain and the region mainly in the field of game development. Since our formation in Early 2017 by Yousef BuHazza.
The community aims to aims to establish an environment that supports local and regional game developers. We recognize that game development is a collaborative effort that combines several disciplines, so to us, game developers are people with different skills that would like to use those skills to develop a game.
Initially the community was focused on developing digital games using Epic Games Unreal Engine, but has shifted to support all forms of game development regardless of the platform and included physical games such as table top games.

Twitter - Linkedin - Web

Denis Dyack - How To Get Into The Video Game Industry

Denis Dyack, a video game industry veteran of more than 30 years, is the Founder and CEO of Apocalypse Studios. His studio evangelizes using a cloud-first approach in game development and partners with AWS Game Tech to move the medium of the games industry forward.

In his years of experience speaking at games conferences and within AWS communities, Denis has been an advocate for building on Amazon Lumberyard and more recently in moving over game development pipelines to AWS.

Denis is also exploring deep Twitch integration for games and continues to find innovative ways to partner Amazon with games communities. He is always excited to share his AWS experiences and passion for his craft with others in the games industry.

Twitter - Linkedin - Web

Panel - State of the Game Dev industry the region.

Community Leaders from Lebanon, Tunis, Egypt, Saudi Arabia and Bahrain will be presenting the latest progress in the game dev scene in their countries, as well as go over the future initiatives to look forward to.

Panelist

Joseph Azzam (Host) - Lebanon

Youssef BuHazza - Bahrain

Nourhan ElSherief, Senior Game Developer - Egypt

Graduated in The Faculty of Computers and Information in 2013, and completed the ITI game development 9-month diploma in 2014. Have had experience working with several studios on several mobile games, till joining Instinct Games in 2016 and been working as an Unreal developer ever since. As a side project, I started Indie Games Corner in late 2016, a blog for spreading awareness about the indie game scene in Egypt.

Houssem Ben Amor - Tunis

Business Development Manager at Nuked Cockroach, Tresorier of GlobalGameJam.Inc, Co-Founder of Tunisian Games Developers

Heroes Trio

AWS Community Heroes Ahmed Samir founder of AWS Bel Araby and Anas Khattar AWS Community Hero as well as AWS Container Hero Walid Shaari took lead of logistics and coordination between all the different communities and speakers.

Landing Page

For the landing page Ouadie Lahdioui AWS UG Morocco Leader used the same static site generator Jeykell which was forked from AWS Community Nordics with a new theme

aws-mena-community / awsmena.community

Follow this tutorial from Aleksandr Hovhannisyan to build your own static site with Jekyll on Github Pages

Getting Started with Jekyll and GitHub Pages: Your First Website

Aleksandr Hovhannisyan ・ Mar 1 '20 ・ 46 min read

#jekyll #github #webdev

Also check the live site here -> https://awsmena.community/gametech

Registration, Broadcasting, Streaming and Graphics

We reached out to AWS regional MENA office in Dubai to create an official registration page for the event https://menagametechday2021.splashthat.com/ which we linked to our landing and agenda page.

We will be using StreamYard for live production and broadcasting to the #1 streaming platform for gamers in the middle east Rawa TV as well as Twitch and Youtube. Links will be sent by email for registrants a day before the event.

Our talented designer Boushra Hassanieh crafted the posts using Canva which is very helpful for custom posts and cover images of the event on Instagram, Twitter, Facebook and Linkedin.

PS5 Giveaway and Conference Feedback

AMD offered a PlayStation 5 console to 4 participants in our post-event feedback survey. The survey will be sent to registrants after the event for feedback and registration in the PS5 raffle.

Register now and lets play one more game!

AWS Well-Architected Framework For Startups

Anas Khattar — Fri, 16 Oct 2020 12:40:48 +0000

As an early-stage startup, you face a lot of challenges with business, technology, talent, and market competition. You have to worry about building your MVP and the latest features you want to add in the next sprint in order to penetrate your market. Here innovation and disruption are your springboards for success. AWS gives your startup a breadth of tools that allow a fast start to deep capability. From essentials like user management, scalable frameworks, and business logic tools to cutting edge image analysis, voice recognition, artificial intelligence, and machine learning, the startups using this technology most effectively will be the ones changing the game.

There is no value in worrying about failing storage or a compromised server. Your teams are usually focusing on the core business product and service it can become challenging to build a system that delivers on your expectations and requirements. That's why it's important to study AWS managed services and follow best practice guidelines to ensure you have the right set of checklists to go through to achieve a “standardized” approach to creating your environment.

Creating a software system is a lot like constructing a building. If the foundation is not solid, structural problems can undermine the integrity and function of the building. AWS has provided these guidelines in a framework called the Amazon AWS Well-Architected Framework built around 5 pillars, Security, Reliability, Performance Efficiency, Cost Optimization, and Operational Excellence. This framework was first introduced by Dr. Werner Vogels several years ago.

Incorporating these pillars into your architecture helps produce stable and efficient systems. This allows you to focus on the other aspects of design, such as functional requirements.

In this post, I provided an overview of the Well-Architected Framework’s five pillars. You can find more details—including definitions, FAQs, and resources—in each pillar’s whitepaper, link below.

Read the full Well-Architected whitepaper >>

Well-Architected Framework

Amazon AWS has created this framework out of their vast experience with Cloud customers, large and small, and have been adopting it since then. Not only, but they changed their certification exams to be built around the Well-Architected framework. This shows the importance and efficiency of following it.

The framework helps cloud architects build the most secure, high-performing, resilient, and efficient infrastructure possible for their applications. It provides a consistent approach for startups to evaluate architectures and provides guidance to implement designs that scale with your product needs over time.

Cost Optimization guides around the ability to run systems to deliver business value at the lowest price point.
Performance Efficiency guides around the ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve.
Reliability guides around the ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues.
Operational Excellence guides around the ability to run and monitor systems to deliver business value and to continually improve supporting processes and procedures.
Security guides around the ability to protect information, systems, and assets while delivering business value through risk assessments and mitigation strategies.

As you see, these pillars are a must for your production cloud environment to ensure that you are running a fast and reliable environment that runs on the minimal cost and in a secure environment. These are the essential aspects of an environment to run.

Certifications

Use the Well-Architected Framework to guide your ideation process as well as to develop Proofs of Concept. You can fit all pieces together by getting your team AWS certified beforehand and then setting post-deployment plans to establish DevOps environments that support scalability and rapid growth.

Read this guide about AWS Certification and Training for startups >>

Once your application is up and running, set up DevOps best practices for capturing and responding to user feedback to drive future innovation.

Defining MVP and Startup Processes: Hypothesis-Driven Development

Anas Khattar — Fri, 16 Oct 2020 11:23:03 +0000

Modern continuous delivery methods demand the use of hypotheses, not requirements, to deliver what customers want. Startups and developers should embrace continuous experimentation and adaption right from the start. So thinking and researching MVPs and writing this down as the closest I could get to define an MVP process or startup process.

First, you should have a hypothesis, you don’t really build something because you can but you want to know what is the right thing to build, what do my customers care about? Also aim to have a tight and measurable hypothesis that's clear and defined.

Then you want to build this, and ideally, you want to build the minimum possible to disprove that hypothesis, if you can’t then you keep going, then you're going to need to measure it, because you can’t disprove or prove something if you don’t measure.

Once you measure you can start to learn and iterate, and as you iterate onwards, you will then start building or altering on that first phase. You can see that build, measure, iterate phase it continuous you keep going round and round and round. Although we have a scale at the end of the diagram above, it's better to think of that as a build measure iterate phase as well there no real distinction between them.

Think about the clarity of what you are trying to achieve, because when you want to measure something you want something that’s singular and within your aim. I speak to a lot of startups but when I ask them what their benefit is, I get a list. It's really always good to start with a really clear and singular mission, something that you can deliver that’s really crisp to your customers.

You want to make sure it's measurable. If you can’t measure it, you can’t know if you succeed against your metric, you might not know what's the right value to get to is but you need at least to have a measure to know where you are in relative terms.

The hypothesis is incredibly important for you to frame what your business is around.

M{x}P

MVP stands for a minimum viable product, its the first product that you build and is the product that gets your startup through the product-market fit phase. It's not a prototype so it's not to be confused with a prototype. A prototype is something you create to see if your idea is feasible if it's like a hardware idea or helps you find a happy path for UX for your users to know how they experience your web app or mobile app. Or just to get a visual so that people can see what are you trying to build. So an MVP is not a prototype, and there are certain situations where you build a prototype before you build an MVP or you might have both an MVP and a prototype to be testing things on the side.

This is the minimum number of features to test your hypothesis, and it is very important because a lot of people overbuild their MVP. It's very common, and you especially see a lot of overbuilding when you have people who never been around software development teams before or worked in a software development team. And overbuilding happens when you build features beyond what is needed to test your hypothesis.

If you want to give a good example of an MVP lets take Lyft for example. What is Lyft trying to solve originally when they first released their product? They are trying to see if peer-to-peer transportation could work. So the minimum number of features they need to test their hypothesis is:

Driver to be able to sign up and log-in.
Rider to be able to log-in and signup.
The rider is able to request a driver and the driver to be able to find that rider.
A form of payment to be exchanged between the two parties which they can take their cut off.

That's all the basic features needed without all the features you see now on Lyft like share your ride on social media or add a stop or hundreds of other features you see now which if they had on their MVP it would have been overbuilding.

There are other kinds or other terms referring to the Minimum Viable Product:

Viable: It's the most referred too commonly and it's a completely new product to test new dimensions of the product.

Usable: Minimum Usable Product is to get your product in the hands of customers and make sure it's usable and get early feedback.

Lovable: If you release a minimum lovable product, you are assuming the product existing in the market is disliked by the customers. And you are releasing a minimum lovable product saying that like I think I can do better than x competitor and here's why.

Testable: Minimum Testable Product is good for risky business assumptions for example Airbnb or Lyft.

“If you aren't embarrassed by the first version of your product, you shipped too late.”
Reid Hoffman, LinkedIn CoFounder

Remember it should be very minimal and it doesn't matter how great the UI or UX looks. It just needs to be functional because you are trying to prove a single hypothesis with the minimum number of features.

I've met a lot of startup founders who are perfectionists (I'm a perfectionist too) but you shouldn't wait until you product is perfect but until it's functional and useful at least at a basic minimal state and ship it out and get people using it and see if they actually like it. Because if they need it and want it they will not really care how it looks like or how beautiful it is. They're going to just start using it immediately. How many people actually care what Lyft looks like. Few people only care because when you need a ride you need a ride. Why do you care if there's a button for me to request a ride? A way to pay the driver. Great, I'm all set.

So it's good if you are a perfectionist that there is someone on the team to push you to ship before you are ready.

Let's take a look at the approach of how you think about your hypothesis or MVP. So if you can imagine this pyramid or stack of what a product is, so this is what you want at the end. You want everything colored in, everything completed, usable, valuable, reliable of course, to scale, and to be a great experience that's beautiful for your users.

I spend a lot of time with people trying to build MVPs and we all try to take a slice of them and build them out. If your a designer there’s a very good chance you’ll start from the top and you’ll have an incredibly beautiful MVP or if your an engineer with an infrastructure background, you’d have an incredibly scalable product, or if your a site reliability engineer, its gonna be reliable, if you're on the business side and get that proposition right, it would be really valuable, or if your an application engineer you’d make a really usable product.

But the question is which one of these do I do? But the simplest way to describe it is if you focus on one of them you don’t want to go super wide.

You want to actually touch on all of them. So imagine this as an approach, your MVP needs to address a certain slice of everything, that's why its really important to think what's the minimum feature that will allow you to build that exact thing.

Product Evolution

MVP is obviously not a customer-facing term, while your first customers are gonna be your early adopters and your product will still need work.

If we are trying to solve the hypothesis of transportation for people we might start with a skateboard then move to a scooter then get more complicated from there. That's why an MVP should be the really bare-bones, it shouldn’t be the wheel or tire and you don’t release it until you have a car. That's an overbuild.

Don’t get distracted with features outside your scope and don’t get distracted by things that don’t prove your hypothesis at its basic core level.

It's better to have something that flows and can be progressively useful as you go on. Each one of these phases could be considered a product. If you were to build the wheels in the first phase and the engine in the second, you wouldn’t have something useful whereas here I can get A to B in the first phase “skateboard to bike to car, I can still achieve the same goal you are trying to do, your vision from one place to another but better and better over time and it's still a minimum viable product at each stage.

Process Mining: A Data-Driven Migration Strategy To Microservices

Anas Khattar — Wed, 08 Apr 2020 15:33:59 +0000

This article aims to highlight a data-informed decomposition of monolithic systems into microservices. Process Mining, algorithms, and techniques used to discover processes based on their digital footprint is a powerful tool that can come handy when migrating to microservices. Event logs generated by monolithic systems can be analyzed to gain an objective view on current flows and usage which can inform the design of better decomposition to microservices.

Process Mining can also be used to dynamically manage microservices and prioritize development efforts. But this paper sheds the light on process mining and its value during the decomposition design phase.

While writing this article with the help of my colleague Nizar Salman, we built on work done by several scholars cited throughout the article and in the reference section, but we were mainly influenced by the work of Professor Davide Taibi.

Why Microservices?

We have seen the use of microservices architecture grow tremendously in the past 5 years, from tech giants to smaller teams the gravitation of microservices is so strong in fact, it’s expected to become the default application architecture within the next five years. Which errors should be avoided in the migration journey while implementing the architecture in order to develop reactive and sustainable systems?

Microservices allowed developers to break down large, complex monoliths into smaller services or applications. Because of their independent deployment, microservices have a lot of advantages. They can be developed in different programming languages, they can scale independently from other services, and they can be deployed on the hardware that best suits their needs even when addressing intelligent IoT applications. Moreover, because of their size, they are easier to maintain and more fault-tolerant since the failure of one service will not break the whole system, which could happen in a monolithic system. Since every microservice has its own context and set of code, each microservice can change its entire logic from the inside, but from the outside, it still does the same thing (Taibi et al., 2017a).

Businesses and organizations are drifting further away from monoliths and closer towards a microservices architecture MSA for every app, website, and digital experience they develop to benefit from better agility, scalability, and resilience.

If you are new to microservices and want to get a hands-on feel of the migration from a monolith to this amazing application architecture, AWS did a great job in this tutorial, Break a Monolith Application into Microservices.

Decomposition Overview

Decomposing a monolithic system into independent microservices is one of the most critical and complex tasks and several practitioners claim the need for a tool to support them during the slicing phase in order to identify different possible slicing solutions (Taibi et al., 2017b)(Taibi et al., 2017c)(Taibi et al., 2018). The decomposition is usually performed manually by software architects (Soldani et al., 2018). Up to now, the only help that software architects can have is based on the static analysis of dependencies with tools such as Structure 101 while the slicing of the system commonly is delegated to the experience of the software architect itself. Moreover, static dependency analysis tools are not able to capture the dynamic behavior of the system and run-time dependencies like frequent method calls could have an influence on both maintainability and performance. Thus, this approach to slicing is based on runtime behavior instead of only considering static dependencies.

At the beginning of a transformation journey, the architects and the development team, with all their know-how and experience, develop a tailored architectural blueprint for the upcoming development. Common steps for migrating from a monolithic system to a microservices one are (Taibi et al., 2017d):

Analysis of the system structure. All processes start by analyzing dependencies mainly with the support of tools (Structure 101, SchemaSpy 2, or others)
Definition of the new system architecture. Architectural guidelines or principles, and the proposal of a decomposition solution into small microservices are defined. The decomposition is always done manually.
Prioritization of feature/service development. In this step, all three processes identify and prioritize the next microservices to be implemented. Some processes prioritize microservices based on customer value; others according to components with more bugs; and yet others prioritize the development of new features as microservices, expecting that, in the long run, the new ecosystem of microservices will gradually replace each feature of the existing monolith.
Coding and Testing are then carried out like any other software development project. Developers adopt the testing strategy they prefer. However, in some cases, testing of the different microservices is performed by doing unit testing at the microservices level and black-box testing at the integration level.

This article focuses mainly on the first two steps, supporting organizations in the analysis of the system structure and in the identification of decomposition alternatives. The architectural guidelines should be defined by the company based on their internal policies.

Data-Driven Strategy and Process Mining

Applications built from microservices should be as decoupled and as cohesive as possible! But how do we pick the best strategy for decomposition? Here are some common decomposition strategies (Richardson, 2017):

-> Decompose by business capability and define services corresponding to business capabilities.
-> Decompose by domain-driven design subdomain.
-> Decompose by verb or use cases and define services that are responsible for particular actions.
-> Decompose by nouns or resources by defining a service that is responsible for all operations on entities/resources of a given type.

The first two strategies are mostly abstract patterns of human decisions while the other two are based on predefined data-driven criteria which this method will focus on.
A data-driven microservices-oriented decomposition approach based on data flow diagrams from business logic. This could deliver more rational, objective, and easy-to-understand results thanks to objective operations and data extracted from real-world business logic (Chen et al., 2017). Similarly, you can adopt process mining to analyze the business processes of a monolithic system.

Tools and Techniques

However, while dependency analysis tools can support the identification of static dependencies, they do not enable the identification of the full execution path. This approach combines process mining techniques and dependency analysis to recommend alternative slicing solutions.
The approach requires the availability of an extended version of a log trace collected at runtime. For each user operation performed from the user interface (e.g., clicking on a button), or from any entry point of a system (e.g., APIs or command line), all the activities must be traced from the log files. Information about each class and method that is traversed for the execution of the operation must be included. The complete execution must be traced completely from the entry point (a click on a submission form or the beginning of an operation) to the access to the database (if any) and to the results returned to the client. An example of data reported in the log file is shown in Table 1.

Table 1 – Example of Log Traces

Here, you instrument the software to produce a log. The log trace must include events that indicate entrance and exit of functions as well as database accesses. Each entry in the log also has a timestamp and a session ID, to distinguish between the usage of the same class or method from different users.
The log trace could be collected by instrumenting the source code with Aspect-Oriented Programming, by adding the log trace into each method or with existing applications such as the Elastic APM or similar.
In case the data collection is not yet in place, you can use Elastic APM, since it allows to easily instrument the code with a minor effort. For some languages (e.g. Java and Node.js) the instrumentation requires the addition of one line of code to the application configuration, specifying the type of log trace required and the logging server URL.

Decomposition Process

Once the log files are created, organizations can start the decomposition following this 6-step process (Taibi et al., 2019).

Step 1: Execution Path Analysis

In the first step, you identify the most frequently used execution paths with a process-mining tool. In this case, DISCO 4 was used to graphically represent the business processes by mining the log files. The same result can be obtained by any other alternative process-mining tool. The result is a graphical representation of the processes, reporting each class and database table used in the business processes, with a set of arrows connecting each class based on the log traces. The result of this first step produces a figure that allows to understand:

• Runtime execution paths of the system. Paths never used, even if possible, are not represented in the figure.
• Dependencies between the classes of the system. The arrows represent the dependencies between methods and classes. External dependencies to libraries or web-services are also represented.
• The frequency of usage of each path. Process mining tools present the most used processes with thicker arrows.
• Branches and Circular Dependencies. The graphical representation allows easy discovery of circular dependencies or branches (e.g., conditional statement that led to different path based on the input provided), in case they exist.

The complete chain of arrows forms a candidate of a process. Figure 1 below represents a simplified example of one business process representing the data reported in Table 1 above.

Figure 1 – Simplified Process Example

Step 2: Frequency analysis of the execution paths

The thickness of the arrows created by the DISCO tool indicates the frequency of the calls between classes. This makes it possible to clearly understand which execution paths are used most frequently and which classes are rarely or never used during runtime. The output of this step is a table representing all the different execution paths with the frequency of their usage.

Table 2 – Frequency analysis of each execution path

Step 3: Removal of Circular Dependencies

In this step, you first find circular dependencies by analyzing the execution paths reported in the table generated in the first Step. This can be done with a simple algorithm to discover cycles in the execution paths. In the case of circular dependencies, software architects should discuss with the development team how to break these cycles. One example of the patterns that can be applied to break the cycles is Inversion of Control (Martin, 2003). However, every cyclic dependency could need a different breaking solution that must be analyzed carefully. The result is a refined version of the execution path table.

Step 4: Identification of decomposition options

Starting with the execution paths without cyclic dependencies obtained from Step 3, you identify different decomposition alternatives by visually inspecting the generated graphs. The candidate processes may have common sub-paths, i.e., the processes may merge or split.
Thus, different decomposition solutions are possible. This process could also be automated by developing an algorithm that provides all different decompositions based on the paths with fewer intersections. However, in this case, you rely on the expert-based decomposition.
As highlighted in Figure 2 below, the decomposition options need to deal with the duplication of some classes or methods. As example, the execution traces reported in Figure 2 below show that both the green and the orange execution traces use j(). Therefore, software architects could propose two decomposition alternatives. The first option includes the creation of three microservices where class E.java() is duplicated in microservice MS2 and MS3.

Figure 2 – Simplified Process Example

The second option includes the creation of two microservices, merging MS2 and MS3. Both options have pros and cons, but the decision of merging two execution traces or splitting into different microservices must be discussed with the team. If two microservices candidates for the splitting have different purposes, it is reasonable to consider the splitting. If they are doing the same thing, then it would be better to merge them into one single microservice for example.

Step 5: Metric-based ranking of the decomposition options

In this step, you identify three measures to help architects to assess the quality of the decomposition options identified in Step 4: Coupling, Number of classes per microservices, Number of classes that need to be duplicated.

A - Coupling

The decomposition to microservices should minimize coupling and maximize cohesion. Coupling and cohesion can be calculated with different approaches. While coupling can be obtained from the log traces, for all the cohesion measures we also need to know about the access to the local variables of each class, which makes it impossible to calculate them from the data reported in the log traces. However, coupling is commonly considered as inversely proportional to cohesion. Therefore, a system with low coupling will have a high likelihood of having high cohesion (Jabangwe et al., 2015). We define the Coupling Between Microservice (CBM) extending the well-known Coupling Between Object (CBO) metric proposed by Chidamber and Kemerer (Chidamber and Kemerer, 1994). CBO represents the number of classes coupled with a given class (efferent couplings and afferent couplings). This coupling can occur through method calls, field accesses, inheritance, arguments, return types, and exceptions.

You calculate the relative CBM for each microservice as follows:

Where Number of external Links represents the number of calls to external services used in each class of microservice. An external service linked several times by different classes of the same microservice is only counted once. External services could be other microservices, external APIs, etc. CBM is calculated for each microservice independently and presented in a table for the next step.

B - Number of classes per microservice

This measure helps to understand how big the microservice identified is and to identify if there are microservices that are too big compared to others. The number of classes should be minimized since the smaller the number of classes the more independent its development can be. Considering the example reported above in Figure 2, the MS decomposition option 1 has 7 classes while option 2 has six classes.

C - Number of classes that need to be duplicated

In some cases, several classes will be in common between two execution traces. As example, the method j in Class E (Figure 2) is used by two execution traces. In the example depicted in Figure 2, decomposition option 1 has one class that needs to be duplicated, while option 2 requires no classes to be duplicated. This measure helps to reason about the different slicing options, considering not only the size of the microservices but also the number of duplications, that will be then reflected in the development of the microservices. Duplicated classes should be avoided since the duplication adds to the size of the system and its maintenance, where they can be transformed into a library/dependency used by both microservices.

Step 6: Selection of the decomposition solution

This is the final step where, based on the different decomposition alternatives identified in Step 4, and on the measures collected in Step 5, software architects can decide which solution to adopt by merging or splitting existing processes. Software architects could consider the recommendations provided by this decomposition process and discuss with the team which solution is most suitable for them, considering the organizational structure. This process does not recommend the best decomposition solution but provides a reasoning framework on the possible decomposition options.

Conclusion

System logs offer a big opportunity to inform the decomposition of IT systems. By applying process mining to logs, main activities and transactions can be discovered. The architect is extended by invaluable and visual information that helps inform better design based on data and real needs.

References

Taibi, Davide & Systä, Kari. (2019). From Monolithic Systems to Microservices: A Decomposition Framework based on Process Mining.
Taibi, D., Lenarduzzi, V., and Pahl, C. (2018). Architectural patterns for microservices: a systematic mapping study.
Soldani, J., Tamburri, D. A., and Heuvel, W.-J. V. D. (2018). The pains and gains of microservices: A systematic grey literature review.
Taibi, D., Lenarduzzi, V., Janes, A., Liukkunen, K., and Ah- mad, M. O. (2017a). Comparing requirements decomposition within the scrum, scrum with kanban, xp, and banana development processes.
Taibi, D., Lenarduzzi, V., and Pahl, C. (2017b). Processes, motivations, and issues for migrating to microservices architectures: An empirical investigation.
Taibi, D., Lenarduzzi, V., Pahl, C., and Janes, A. (2017c). Microservices in agile software development: a workshop-based study into issues, advantages, and disadvantages.
Richardson, C. (2017). Pattern: Microservice architecture.
Jabangwe, R., Bo ̈rstler, J., Smite, D., and Wohlin, C. (2015). Empirical evidence on the link between object-oriented measures and external quality attributes: A systematic literature review.
Martin, R. C. (2003). Agile Software Development: Principles, Patterns, and Practices.
Chidamber, S. R. and Kemerer, C. F. (1994). A metrics suite for object oriented design.