Concorde Effect Fallacy Conundrum when building Microservices - Series Part 3

One major point of argument that I have come across in every team when building micro-services is to Use the existing code or rewrite the code?

When building new functionality the majority of the time it makes sense to rewrite capability and not the code. This may be time-consuming to build, but the monolithic platform already has a lot of redundant code.

By rewriting capability it gives an opportunity to improve the granularity of the service, revisit business functionality, and maintain a clean codebase.

Business and IT teams always spend a lot of money on solutions that are deemed to be the right way. But, many a time the only reason these extravagant solutions are running is because they are spending a lot of money on it.

One of the teams that I was part of the business spent a huge amount of licensing money every year on a proprietary solution and were hesitant to change.

However, the software was pretty tedious and it was very slow building functionalities. The team started with a POC and realized that in a few weeks they could build the same core functionalities with open-source software. They went ahead and did that and it opened up a surfeit of opportunities for the business team to improve upon.

Be rational in decision making and avoid sunk cost fallacy situation.

Stay practical in what needs to be rewritten and what needs to be reused. Sometimes the later may be a good choice as not everything in the monolith is a throwaway.

In another instance, one of the teams were struggling to re-architect complex business functionality and moving very slow. The business knew that this was going beyond the scheduled budget and time and did not yield many benefits, but they struggled to decide to dismantle the team.

It’s never too late to pull the plug when building services. In situations where certain core functionalities built don’t change much just reuse stuff. Maybe a good code review is what is required.

Socio-Technical Approach to building Microservices - Series Part 2

Once the initial approach is selected, the next challenge is defining teams and how to manage the key challenges to attain velocity and sizing within teams.

A socio-technical framework is being used more and more when building complex systems, especially those that deal with the principles of working in teams and agile environments where adaptability is the key. Below are a few common questions that the teams need to dwell upon and ask themselves?

How big a microservices application has to be? Should it be a Micro, Macro or even a Mini service?

How to keep in context without swapping out or referring documentation, or human intervention?

How to embrace changes in the application? How to build software that is faster time to market?

How to bring in a new person and develop without any wait times?

The concept of “Cognitive Load” is getting used quite often when sizing microservices. The concept has been borrowed from the psychological dictionary where the cognitive load refers to the information one keeps in the head without referring to something else. It’s a universal concept used for learning and to help maintain optimum load on the working entity. It can be defined as a temporary working memory like a Cache or Ram.

“Producing maintainable software depends on readable information be it code, modules, or documents, and readable information depends on controlling Cognitive Load.”

There are three types of Cognitive Loads defined

• Intrinsic Load is related to the complexity of information that a team is paying attention to and processing. It’s bae skills and demands on specific tasks or technology that one is grasping and the difficulty of learning the task itself. In building microservices this can be the initial load that is required to create an end to end service.
• Extraneous load is completely unrelated to the learning task. These are all the negative distractions and additional effort imposed on the team or system.
• Germane load is the mental processing effort and is directly going towards supporting of development of schema and long-term memory. In building software, it is the repeated decorative knowledge and conglomeration on how this thing to play in a more complicated system.

Intrinsic and Germane load are considered “good” and Extrinsic is “bad”.

Always in teams try to find and offload those extrinsic loads that affect the teams.

The extrinsic loads identified in the teams that I was part of included environmental issues, complicated subsystems, unnecessary complex or business Logic, complex code, misfit teams, team meetings, etc….

Many a time, it could also be as simple as spending time on unnecessary documentation that no one reads or to over-complicate the code or even spending hours contemplating method and object names.

Too much Germane load makes learning a new task harder and slower.

Microservices have a handful of moving parts at the same time and more the moving parts, to begin with, the complicated it gets. Systematic tradeoffs need to be made by teams when building services. Teams have to communicate and learn from each other.

The Intrinsic load should reduce over time as new lower-level knowledge and experience are formed and documented.

Always try to complete that initial simple microservice end to end, and deploy it in production with a database, CICD, alert and monitoring system, testing strategies and version control in place. This makes the subsequent services to be carved out more easily. After a few services spinning up new services and it becomes a cakewalk.

As the experience increases handling cognitive load gets more mature and achievable.

Unraveling the Plethora of Gaffes in a Microservices Odyssey - Series Part 1

Microservices in the last few years has become a hackneyed concept and the modus operandi methodology for building applications to drive digital transformations. The so-called adoption of modern Hydra with tentacles to replace the legacy one-eyed Cyclops seems what most organizations are striving towards when strategizing Modernization, Cloud adoption journeys or Agile and DevOps ways of working.

After spending few years learning and understanding the platform revamp of moving away from a bulky monolithic commerce platform to service-based architecture, I have learned myriad ways on how IT organizations bungle up a journey and at times come a whole full circle.

There is no direct method to this madness but for sure are best practices and learning from earlier blunders and possibilities to circumvent hidden traps and pitfalls.

The Onset Enigma

The inception of the microservices journey is typically to combat the imponderable conundrums pertaining to “Slow time to market”, “Complex and heavily customized applications”, “Testing nightmares”, “Scalability and Stability issues”, “Velocity,” “Technology binding”, “Adopting modern stacks”, “Continuous Integration and Continuous Delivery”, “Cost factor” and locking vendor licensing model” and the list goes on.

Microservices approaches differ from organization to organization and there is no ready-made panacea. I have time and time seen teams perform a mere replication of these approaches resulting in incurring insurmountable technical debt.

Before embarking on a microservices journey, it’s essential to comprehend what issues one is trying to deal with and where one needs to start?

A lot of initial time has to be spent to understand the “complexities of the existing monolith”, “core issues with the legacy”, “technology forecast”, “business limitations”, “future business requirements”, “organization processes”, “their strengths and weaknesses, “team sizes”, “operational readiness” “ways of working” , “cultural standpoint”, “integration dependencies” and several other factors before choosing an approach.

It’s pretty common to see that modern IT teams yearn for re-architecting existing monolithic applications and move away from the mundane system to a more services-oriented modern stack and technology.

But, before even attempting the journey, teams need to evaluate if the journey is worth the endeavor? Typical questions teams need to ask themselves

• Maybe the release cycles of the monolith are of way too less frequency and just leaving it alone is the best solution?
• Maybe the monolith is of a specific size and estimated to not grow further?
• Maybe the organization is not ready yet to begin the journey from an operational, technology, process or even from a cultural point of view?
• Maybe there are way too many features in the monolith that is more crucial from a business and cost standpoint?
• Maybe the monolith has a short lifespan and is getting replaced?
• Maybe the organization is not yet agile or has not yet adopted DevOps which is pivotal for a microservices journey?
• Maybe breaking the monolith is way too complex and it is easier to rewrite code from scratch using new software?
• Maybe building new features is of more priority than breaking out new services?

Sizing an Application

Capacity Planning of Web application.

Recently we have been observing that the website that I have been part of has been running on average constant response times for different peak loads. At this time, we had moved lot of the functionalities to different applications on the cloud where scalability is auto managed.  This made us revisit the number of instances that we have been running in production on our on-premise servers. If these servers were required for the peak load and validate if we could save some money and maintenance on the infrastructure by reducing certain number of servers.

This required re calculating the capacity planning for different environments. To calculate the approximate capacity or how much traffic an application can hold up is based on different data points.

These datapoints include factors number of requests per second, average application server response times, number of instances and their details of CPU, cores, threads, sockets etc. All the required information typically can be gathered from the analytics tool like GA, or Adobe web analytics or monitoring tools like new relic, Dynatrace etc.

Calculating the number of Cores?

For doing this all we need is to load the cpu information (lscpu) and view the information related to Threads per socket, Cores per socket and number of Sockets. In the below case the number of core = 6 * 1* 1 = 6.

This value is for a specific instance or virtual machine and the total cores is calculated by adding  all the virtual machine specific cores. For e.g. If there are 4 virtual machines then the total number of cores present in the infrastructure based on the above alogirthm is 4 * 6 = 24.

Calculate the maximum load or through put of the system?

The next step is to calculate the number of average requests to the application servers. This can be calculated by viewing the data of the monitoring tool. The information needs to be fetched for the most peak traffic or expected peak traffic for an application or website. For e.g. If the peak throughput for an application is say 1000 requests per minute. Then the value in RPS or request per second is 4000/60 = 66.66

Calculate the Average response times?

The next value that needs to be calculated is the average response times from the application server. This information also is available using any monitoring tool or can also be calculated by using the expected average value in seconds. For e.g. Assuming 250 m sec to be the average app server response time.

Now with the required information in place the number of cores can be calculated using the formulae

Number of cores = Requests per second * average response time in seconds

For.e.g Number of cores for peak traffic = 0.250 seconds * 66.66 = 16.665 cores. (app 17 Cores).

Key Architectural Considerations to Evaluate when moving applications to cloud - Part 2

  Ø  If an application migration requires lot of integration or coordination between internal and external environments on top of the cloud services, it will become a layer between the cloud provider and inhouse applications will struggle to keep up with the rate of innovation in the cloud provider’s services. Cloud provides numerous services that are portable. Organizations should not build or acquire layers of insulation on top of cloud provider's native features in order to perceive portability.

  Ø  Modern cloud service providers can auto scale in order to create a resilient and highly available applications. The cloud service providers have different solutions to provide the ability to store and replicate data. If a legacy application is critical enough to meet the requirement of fault tolerant,  moving such applications to the cloud can be easier to manage.

  Ø  Cloud is a better fit if Speed and Agility are the primary business drivers of an organization. In order to do so it is required for applications to have continuous and direct access to the cloud provider's fast pace of innovation. Only by building directly upon provider-native features will there be the desired business agility and rate of improvement. Organizations will struggle to easily port applications across cloud providers by sacrificing speed, agility and innovation.

  Ø  Another area to consider is the factor of repeatability for applications. Typical scheduled deployment times in legacy application require a down time along with human intervention in doing the same manual tasks repeatedly. Also, in case of disaster recovery or outage most of the tasks carried out are manual. Typical cloud services excel to execute the same tasks multiple times without failure. Most of the application recovery or deployments are auto managed and incur very little to no human interventions.

  Ø  Cloud services generally provides high flexibility and testability. Applications can be tuned to run on need basis. Test environment application can be a good candidate to move to the cloud especially when doing a load or stress testing. Different applications can be made available on the fly based on different hardware configuration, operating system and different regions and can be scaled up or down on need basis. This gets even easier with cloud providers excelling in containerized application and providing seamless continuous integration and deployment.

  Ø  If high performance, monitoring, volatility and high volume are the key requirement then the application needs quick development and high rate of innovation.  Cloud vendors do provide ready-made solutions to meet all such requirements. Performance benchmarks can be met with different solutions that fulfil the key constraints of Caching, Sharding, Archiving and Storage. Readymade tools can be configured to meet the requirement of in-depth monitoring, logging and analysing. Cloud providers have rich support for state-of-the art agile development modes including DevOps, containers, microservices and will be the first to have mature support for upcoming methods like serverless computing etc. Different pricing models and tenancy are also provided that can ensure cost is kept to the minimum.

Approach on what pages to move first in a microservices journey

Every microservices journey is different for different organizations based on their core competency. However, few of the basic elements of where to start and where to end are more or less similar. Came across this below diagram on multiple websites which illustrates the typical migration model. Read only pages or static pages with content are much more easier to move to newer platforms especially on cloud services like SaaS than core business components.  

Key Architectural Considerations to Evaluate when moving applications to cloud - Part 1

  Ø  Elasticity is one of the major benefits of moving to the cloud. What it essentially means is that the servers can be scaled in or out as needed. While the cloud offers both horizontal and vertical scaling of applications, it’s the horizontal scaling feature that reaps major benefits. If elasticity is the not a key concern, then the application readiness for cloud needs to be evaluated as it could be a better fit to be managed on premise or on a hosted solution.

  Ø  Most of the legacy application mainly scales vertically where the application is dependent on core infrastructure and are tightly coupled with inhouse hardware (low latency + high intensity, or high bandwidth) and specific software and technology stack. Moving such applications to the cloud can create lot of complexities and can require lot of rearchitecting. Also, moving such applications makes them look like a hosting solution instead of a loosely coupled cloud solution.

  Ø   Modern cloud services rely mainly on databases which follow BASE properties, (Basically available, soft state, eventual consistent transactions), and CAP theorem (Consistency, Availability and Partition Tolerant) i.e. if the transactions fail the data will become eventual consistent. Legacy applications are typically monolithic, and the underlying data is mainly designed for ACID transactions, (Atomicity, consistency, isolation, and durability), i.e. transactions are not complete until the data is committed. Applications can get complex to function in the cloud and make use of core cloud features if they are not capable of meeting the goal of eventual consistency and Partition tolerant.

  Ø  When moving application to the cloud another property that needs to be evaluated is the aspect of application state. Cloud is suited well for an application that is stateless, i.e. when the client is unaware of the state of the server. Stateless applications are also easier to size and cache on the cloud. If the legacy application is stateful, i.e. the application has lot of dependency on infrastructure. It will get complex moving them to cloud considering the different requirements around sizing, capacity planning, caching etc.

  Ø  If applications require lot of security and compliance, the organizations also share responsibility with the cloud vendor for lot of IT management if they are moved to the cloud. Organization not only need to maintain adequate governance but also are responsible for meeting the required compliance and audit standards. While most of the major cloud vendors do provide increase IT security including Intrusion Prevention Systems, Web application firewalls, Runtime application self-protection, converged application performance and security monitoring, botnet and DDoS mitigation mechanisms to meet the regulatory standards. Moving such applications to cloud can be more of a hassle in terms of management, quality adherence, maintenance etc than keeping them inhouse.

  Ø  Connectivity and Interoperability is another key consideration when deciding to move applications to the cloud. Every major cloud provider does have the ability to either connect directly or via a virtual private network. But this requires organization to cover up all the critical loopholes for such connections in the targeted and dependent applications. This can be a very tedious task and can lead to several challenges if the organization is not ready. 

How to decide to move legacy applications to Cloud

Understanding role of DNS

Building applications for High Availability or Fault Tolerant

What type of Private Cloud should organization invest?

Private cloud computing is a form of cloud computing that is used by only one organization that is isolated from others. A private cloud is unitenant and prevents exposure of data to external world or internet and results in better performance with less security risks.

A private cloud or the enterprise cloud resides on company’s intranet (internal data center) or hosted data center where the firewall protects the data. Hence, they are classified into two categories

    
       a)    On Premise Hosted Private Cloud   

      b )    Off Premise Hosted Private Cloud

In an On Premise Hosted private cloud the organization has to take care of the all the infrastructure including maintenance, licensing costs etc. Whereas in the Off Premise Hosted Private Cloud solution all the overheads are outsourced to the managing vendor.

In either of the categories one major advantage of Private cloud is that it offers a dedicated secured storage of infrastructure that is not accessible to others. Thus, providing enhanced security and further option to implement various levels of authentication and security for the infrastructure. Further organizations can decide to choose the one or more data centers either on premise or with dedicated service providers.

On Premise Hosted Private Cloud requires initial investment of dedicated hardware infrastructure and hence is suitable for organizations that has determined its cloud priorities with existing infrastructure cost or that require less investment in cost of new infrastructure. Organizations with existing data centers can look at this option as they can utilize the existing infrastructure to move to private cloud.

Since the organization maintains the infrastructure, licensing cost, management of upgrades, installations, maintenance and administration has to be done in house. This can be expensive and not suit organizations that require additional cost in investment to setup on premise or service provider-based data center and administration costs.

One of the other advantages of On Premise Hosted Private Cloud is that it allows customization of their cloud infrastructure according to the business needs and increase scalability and flexibility. However, this is also a disadvantage for organizations where on demand need for scaling virtual computing services is a challenge.  

Private cloud also suits organizations that are investing in the growing awareness of the advantages provided by virtualization technology. It enables organizations to improve infrastructure cost, performance and improve usage of underutilized hardware.

Hence, investing in On premise hosted private cloud is a good option for organizations with considerable predictability and consistency in infrastructure cost and demands. Organizations that have existing services and that can depict data related to infrastructure usage and statistics are in a better position to handle the demands and avoid the cost issue of under-utilized infrastructure. Also, this service suits organizations for whom control and security is of top most priority.

Off Premise or external hosted private cloud can be an option if organization want to be unitenant and cannot afford to scale, maintain and administer the On Premise Private cloud.

Getting website content relevance right

If you have come across a search results page where the top results are irrelevant to the search term entered the majority of the time, it's due to the incorrect setup of Relevancy ranking. Relevancy Ranking of products on Search and Browse pages is the critical search feature that easily gets ignored on several retail sites. 

Most of the modern enterprise search engines provide an easier way of handling relevance using business tools. However, understanding the algorithm and the fitment behind these results is not simple. Online businesses generally have a standard retail strategy applied for relevance, but this may not be applicable for every domain. As complexity increases with data corresponding to multiple sources, locales, and applications, the Relevancy Ranking requires some fine-tuning. 

Below are some of the measures that need to be factored into to improve Website Product Relevancy Ranking:- 

Monitoring Search Results

Use analytics to monitor user behavior on the search and browse results. Information like most clicked products, most popular searches, error results, spell correction, and page behavior gives an indication of how relevant results are shown to the user. These data form the basis of boosting required results and ignoring irrelevant results. 

Interpreting the data

As the online business grows many online retailers fail to understand the importance of data updates. With the creation of huge product-specific properties, understanding the attributes associated with the right data helps to display relevant products in the right order. Applications need to have the real-time capability to refresh this data timely and getting it to end-users in the shortest time possible.

Prioritization of Attributes

Attributes precedence is key for relevancy. There needs to be a clear definition of the data associated with these attributes. Special considerations have to be taken for data like Category Name, Product Name, Descriptions, and other keywords, as these attributes form the basis of the Search Engine Index. Custom attributes can be created as required and added to the prioritization list.

Relevancy Ranking Algorithm

Teams that are responsible for creating Product data have to be well versed with the relevancy ranking modules and their impact on the end online user. Each ranking module is executed during the relevancy ranking process and ranks the results. Teams need to ensure that at the end of every execution if there is a tie-break, appropriate results need to be segregated and ranked as per precedence. 

Enterprise Search Engines

The setting of core search functionalities like Synonyms, Thesaurus, Stemming, Spell Corrections, Did you mean, Most Popular, etc play a vital role in displaying the relevant results. For sites having multiple locales custom stemming files have to be maintained. Also, it's very essential to keep building the dictionary as and when new data sets are added. Many modern search engines provide all the above features Out of the box as an administration tool. 

Who should invest in a private cloud?

Private cloud computing is a form of cloud computing that is used by only one organization that is isolated from others. A private cloud or the enterprise cloud resides on company’s intranet or hosted data center where the firewall protects the data. This prevents exposure of data to external world or internet and results in better performance with less security risks.

One major advantage of Private cloud is that it offers a dedicated secured storage of infrastructure that is not accessible to others. Thus, providing enhanced security and further option to implement various levels of authentication and security for the infrastructure. Organizations can decide to choose the data center either on premise or with dedicated service providers.

Another advantage that should be considered by organizations is that Private Cloud allows customization of their cloud infrastructure according to the business needs and increase scalability and flexibility.  Private cloud also suits organizations that are investing in the growing awareness of the advantages provided by virtualization technology. It enables organizations to improve infrastructure cost, performance and improve usage of underutilized hardware.

Private cloud requires initial investment of dedicated hardware infrastructure and hence is suitable for organization that has determined its cloud priorities with existing infrastructure cost or that require less investment in cost of new infrastructure. Organizations with existing data centers can look at this option as they can utilize the existing infrastructure to move to private cloud.

Since the organization maintains the infrastructure, management of upgrades, installations and administration has to be done in house. This can be expensive and not suit organizations that require additional cost in investment to setup on premise or service provider-based data center and to hire dedicated administrators.

Hence, investing in private cloud is a good option for organizations with considerable predictability and consistency in infrastructure cost and demands. Organizations that have existing services and that can depict data related to infrastructure usage and statistics are in a better position to handle the demands of private cloud.