Five Signs Your FBA Business May Flop, Part 2

This is part two of a five-part series addressing concerns around “Is an FBA business profitable.”  In part one, I discussed “creating a hustle vs. building a business.”  Part two is concerning building a brand other than your own.

Building a brand other than your own

Building a brand is the goal of the vast majority of businesses.  Just saying that you have a brand isn’t enough, though.  And while brands and brand marks are properties of a company, they don’t reside in the company. 

A brand is what resides in the hearts and minds of your prospective customers when they think of the products your company offers for sale.  An example of the conflict between what a company wants to brand and the results of their efforts is the Chevrolet Nova from the 1970s. 

When the US car manufacturer named their Nova car, they focused the product to the muscle car enthusiasts market.  The term nova refers to a sudden burst of energy—at least in the US.  While the car was popular in the US, it never took off in Mexico. 

The reason?

The Spanish meaning of nova is “not going.”

So, car buyers in the Mexican automobile market didn’t want to drive something that, in their minds, wouldn’t go anywhere. 

The goal of a brand-building

The goal of brand building is straightforward. 

The goal is to leave an impression of your company’s goods and services that set you apart from the crowd. 

It is to be different – unique. 

It isn’t just having a domain name!

There are two basic models that you can employ to attempt to build a brand.  The models are mass market and niche. is an excellent example of a mass-market brand.  Even when started as an online bookstore, they attempted to position themselves for the masses through advertising. 

The second basic model you can employ in brand building is niche segmentation.  People often overcomplicate the concept of a niche approach—it’s any segment of the overall mass market. 

A hypothetical example of this approach would be if either: stayed in only the bookseller business, only served the western US, etc.  A niche could be tiny, or it could be enormous.  The main thing to keep in mind concerning the model is that you are only trying to serve a portion of the larger market. 

When starting an Amazon FBA company, the default is to focus on a niche.  Not because the founder wants to stay within that niche.  The reason is likely due to minimal startup capital.  Most likely, a founder will pick one or two categories or products and form a company around them. 

This is where a lot of founders interested in building a brand start to fail.

Who’s brand are you building?

The thought process goes something like this:

“I can buy something from China, ship it into Amazon FBA, and I’ll make a ton of money because Amazon is the world leader in eCommerce sales and Amazon markets for me!”

It doesn’t work like that.

Yes, you can buy stuff relatively cheaply from China and ship it into Amazon FBA.  Yes, Amazon markets for you, and you will likely make sales—maybe even a lot of them. 

But, so can anyone else in the entire world!

The level of competition on Amazon is high and growing every day.  Even with keywords that are classified as “low competition,” there will still be competitors.  And in the presence of competitors, what happens? 

Margins decrease. 

That means, after you take the risk of buying products and shipping them into Amazon FBA, paying storage fees, etc., you may make a few pennies on the dollar that you invested. 

Who does that benefit? 


Amazon’s brand proposition includes providing customers with a wide selection of products at reasonable rates delivered quickly. 

What about your brand? 

Chances are the consumer picked your offering because it was the cheapest among the “sea of sameness” that returns from an Amazon search. 

Take a guess who else wins with this approach.

The winners in this model include the software providers and Amazon training course providers that helped you select the product to offer via Amazon FBA. 

Is it a lost cause?

Heavens No!

eCommerce is not only alive and well; it is a growing reality in our lives.  That is where people get taken advantage of–they believe the hype. 

What does it take?

First, you need to shift your mind from building

-an Amazon FBA business to simply building your business. 

-Amazon’s brand to simply building your brand.

-a software or training provider’s brand to building a future for yourself and your family.

Once you do that, the most critical phase is over.  By putting the opportunity in perspective, you have accomplished something significant.  From that position, doors open as you learn and then apply your new knowledge. 

It is a journey, but the journey is rewarding. 

Note: For full disclosure – the story of the Chevrolet Nova is somewhat disputed. Academic researchers have found it to be accurate while has found it to be false. What has not been addressed, though, is how much time was required to allow a brand perception to be swayed by the actual performance of the product. In brand-building, that is a key consideration.

Five Signs Your FBA Business May Flop, Part 1

This is part one of a five part series addressing concerns around, “Is an FBA business profitable.”

In April 2020, Coronavirus lockdowns began around the world.  Businesses faced a dire situation—transform or die.  Small businesses were particularly susceptible to the potential of insolvency because they lacked diversity in how they were able to generate revenue.  Business strategists quickly forecast the impending failure of “old-model” businesses and the growth of “new-model” businesses.

As lockdowns began in April 2020, unemployment in the US skyrocketed to 14.8%.  Businesses in the travel and entertainment industries saw revenue decreases of 90+% in a matter of days.  Health Departments forced Hair Salons to close their doors and prohibited stylists from seeing clients.  As the government desperately tried to curb the spread of the virus, citizens desperately tried to survive under a “new normal.” 

Business owners and employees saw first-hand that they were susceptible to a different class of business risks – lockdowns.  They also saw real-life examples of how eCommerce or digital delivery of services could help strengthen or diversity their revenue or income streams.  The idea of “selling online” was no longer something to put on the back burner until they had time.

Selling online became imperative. 

One avenue of selling online that many businesses and individuals have turned to is Amazon’s FBA service.  Amazon FBA is Amazon’s Fulfillment by Amazon.  In addition to allowing other people to create listings in the Amazon marketplace, Amazon enables people to send inventory into the Amazon warehouse. Amazon will effectively treat that inventory like their own.  Amazon will shelve, pick, pack, and ship the third-party products and provide the same level of “Prime” service to their customers. 

It makes selling online easier for small operators—but does it make it profitable? 

I have seen five warning signs in my research that may lead to an FBA business not being profitable.  If a business venture isn’t profitable, it will lead to either bankruptcy or burnout over time.  Being aware of these signs allows you to make course corrections.  

If these signals exist in your FBA business, it doesn’t mean that your business will fail.  However, the existence of multiple signals should give you a reason to be concerned.  If you take note of them and do something about them, you can correct the course and plot a different direction. 

Created a hustle vs. building a business

Most businesses start as, what I refer to, as a “hustle.”  There are many different meanings of the word “hustle” that can apply in this context.  The first is the most negative—being a fraud or a swindler. 

They do exist on Amazon.

The bad type of hustle

One case is a seller who will create a merchant fulfilled listing on Amazon at a high price.  When someone places an order, they will go to an alternate site like, place an order, and have it shipped directly to the Amazon customer. 

You may think, “What’s wrong with that?”  Well, it’s a violation of Amazon’s terms of service. 

When a customer buys from Amazon, Amazon wants their customers to know it is from Amazon.  They don’t want their customers redirected to other marketplaces or businesses.

Is that fair? 

It doesn’t matter because the seller agreed to when they applied for a seller’s account in terms of service.  When Amazon finds out, the seller will be banned, and their “FBA business” will be shut down.

In another case, a seller will create a merchant fulfilled listing as in above.  This time, however, they will use Amazon to send a “gift” to their customer. After the order has been delivered, the seller will contact whoever they bought the product from on Amazon and claim it was lost in shipment and request a refund. 

This scenario may work for a while.  But Amazon keeps track of people who submit too many A to Z claims.  Eventually, that person’s account will be blocked, and their hustle will be brought to an end. 

In both of these cases, it may work for a while, but it won’t last.  Eventually, you will flop. 

The better type of hustle

Stepping out of the mud involved in the types of hustles discussed below is a better alternative.  With this type of hustle, you obtain something with forceful action or persuasion. 

This type of hustle is how most businesses start. 


work hard;



make things happen;

earn every penny you make. 

Creating a hustle-based FBA business can be profitable, but it can also become exhausting.  A common situation with a hustle of this type is when your dollars per hour of work is low compared to your reference point. 

Your reference point usually is your salary from a full-time job.  If you are currently earning $35/hour at your full-time job, a hustle where you earn $25-$45 per hour may be very satisfying.  However, if you are currently making $75-$80 per hour at your full-time job, earning $35/hour in a hustle may be frustrating.  Frustration leads to burnout.  Hitting that burnout stage will likely lead to your FBA business being a flop. 

Building a business

Even with businesses that began as a hustle, there was a transition plan. The transition is to bring additional people or technology into your hustle to remove the need for forceful action or persuasion. 

The goal is to make your FBA business profitable in the long haul.

It’s about:

building processes;



It’s about finesse rather than force.

A typical signal to determine if you have a hustle versus a business is to take a month off and see what happens to your income. 

If even the thought of taking a month off sends shivers down your spine – you have a hustle.  But, if your view is, “Ahh, the team’s got this!” You likely have a business. 

Making the transition from creating a hustle to building a business can be lengthy—and it should be prolonged.  Getting the right people and processes on your team can take a while.  But, when you have them in place, you will have a new sense of freedom. 

If you are blessed to be someone making $75+ per hour in a full-time job, setting up an FBA business making $25 per hour operated by a virtual assistant that you pay $10 per hour becomes much more tolerable.  Absentee owner small businesses exist all over America.  There is no reason why an online business can’t manage in the same manner. 

Hustle versus Business

In this first sign that your FBA business could ultimately lead to being a flop, I’ve shown how being a fraud or a swindler can result in your Amazon seller account being disabled.  I’ve also demonstrated how approaching your business solely through forceful action may result in burnout.  Both of these avenues would lead to an FBA flop. 

I have also shown how building a business can create freedom. 

Freedom comes from creating options. 

IBM Leapfrogs Other Public Cloud Providers with Targeted Ecosystem

While AWS and Azure are recognized as the most prominent players in the public cloud wars, IBM has taken a solid foothold in the public cloud space.  AWS and Azure have created environments for companies to build scalable, robust infrastructure.  IBM’s recent tactic has been to create an environment for companies to do much more—participate in an industry ecosystem.  

In creating the financial services ecosystem within their cloud environment, IBM has established something that the other cloud providers have yet to make—context.  Each industry has its own set of nuances, challenges, and forces that act upon it.  Those issues impact every company that participates in that industry.  No single company is immune.  But through creating that industry context, IBM has also given ISVs a motivation for building their capabilities in the IBM Cloud.  

The benefit of an ecosystem 

IBM has a triple win.  IBM established an ecosystem that banks are motivated to adopt due to security and regulatory functionality. ISVs are encouraged to offer products in the ecosystem due to the number of customers in that ecosystem.  With many ISVs providing services in the ecosystem, more financial services could join the ecosystem.  Soon the IBM Cloud for Financial Services could benefit from a network effect of having a large footprint of clients.  

The critical aspect of IBM’s cloud offering is that they have created an environment where interdependent components of, in this case, the financial services industry, can work together.  By deploying this ecosystem on a cloud computing platform, IBM has allowed this interdependent behavior to be consumed on a ‘pay-as-you-go’ basis.  

The IBM Financial Services ecosystem must attract a wide variety of stakeholders to be successful.  The foundation of the ecosystem is a set of established companies.  However, just attracting established companies is not sufficient. The ecosystem must also possess a circle of life.  The circle of life, in this case, is the creation of new businesses that provide updated functionality to the industry.  Therefore, the ecosystem members must include universities, the developer community, accelerators, and startup companies.  Each member of the ecosystem becomes reliant upon the ecosystem for its continued viability.  

Universities need platforms for teaching their students and research.  Developer communities need application programming interfaces.  Accelerators need tools and capabilities. To sell their products, startup companies need a market.  Established companies need new functionality provided by startups, market opportunities for growth, and workers from the universities and developer communities.  

Why cloud computing isn’t enough

The strength of cloud computing is in its flexibility.  Cloud computing allows a company to scale up and scale down its resources as necessary based upon traffic demand.  Handling traffic demand is a technology problem.  It isn’t a business problem.  

When Harvard Business School professor Michael Porter presented the value chain concept, he listed technology as a supporting activity to the primary activities.  The primary activities are inbound and outbound logistics, operations, marketing and sales, and service.  Companies participating in an industry ecosystem have access to the external processes that drive growth in that industry.  Companies participating in an industry ecosystem also have access to the tools, customized for that ecosystem, that increase business productivity internal to the company. 

When a company migrates their technical infrastructure to the cloud, they gain quite a few efficiencies. However, the basic process largely remains the same.  The technical service owner identifies the need for a new server, they request a new server, they request software be installed on that server. Then the server gets introduced to the production environment. A business can introduce a cloud-based server into production in a fraction of its time to introduce a server into a legacy data center.   

It is a locally optimized solution.  

However, compared to an ecosystem, just leveraging cloud computing will likely not be enough to compete—especially when all industry participants migrate to the cloud.  As an example, a business can shorten a process’ cycle time through automation.  The highest level of improvement possible with automating a given function is a 100% cycle time reduction.  However, by reengineering the entire process,  a business can reduce cycle time by orders of magnitude.  

Ecosystems provide that orders of magnitude impact where cloud computing in itself does not.  

What to watch for

Companies are working toward maturing their enterprise architectures to increase their ability to execute on their strategy.  To date, companies have been focused internally on that maturation process.  However, there will come a time when companies will need to turn their focus externally.  The goal of a company looking beyond itself will be to have seamless integration with external business partners.  With that seamless integration, the core company will have the ability to swap in and out entire companies that would comprise a virtual corporation.  

That level of integration is only possible when an ecosystem is built upon a common object and interaction model.  If that comes to pass, the amount of flexibility that established companies will possess would be outstanding.  Companies could introduce new functionality quickly. Startup companies would have fewer barriers to marketing and selling their products.  The introduction of innovation could be constant.  

Disclaimer:  While not an employee of IBM, the author is a 2020 IBM Cloud Champion.  

Digital Transformation IT Survey

Thank you for taking the time to complete this short survey. The intent of the survey is to capture your perspective of the greatest need of your organization’s IT function and the one area that seems to be getting the most attention.

All responses will be kept strictly confidential and only attributed to role and industry.

Digital Transformation Survey

  • IT departments conduct work on a variety of fronts every year. From your perspective, if they could focus on a single area, what would it be?
  • IT departments conduct work on a variety of fronts every year. From your perspective, what appears to be the one area receiving the most attention by IT leadership?
  • What is your primary role in the organization?
  • Main industry your organization operates within.
  • This field is for validation purposes and should be left unchanged.

Looking Back to See the Future

In reading this Forbes article from Lisa Caldwell and Sachin Lulla as well as several other pieces that I have read, it is becoming apparent to me that we are attempting to move into a direction where we treat our organizations and supply chains similar to how treated semiconductor fabrication factories in the 1990s. During that time the push towards in situ monitoring generating tons of data being fed into control charts as well as factory performance models attempting to optimizing flow through the factory accounting for equipment failure, etc. was relentless. The one thing that really held them back at the time was the lack of a common data model that was shared by all the components of the factory as well as the manufacturing execution system.  

While the complexity of modern supply chains demand tools like discrete event simulations to be able to analyze impacts of disruptions, I’m concerned that the lack of common data model could limit the usefulness of those tools. Utilizing resident entity models may help with the lack of a common model–just not sure yet.  

I’m really not sure at this point, but the way forward may be assisted with what our predecessors learned fixing smaller scale issues in the past.

Knock Down the IT Silos

One of the productivity thoughts put forth in this article is to create automated processes for low value work. Their plan of attack? Ask a friend in your company’s IT function to help you. That’s a good concept but normally it won’t get you far. Most IT shops are busy delivering high value add functionality. They have backlogs that are governed by product owners and a kanban board that prioritize delivery based upon value. If the request is for automating a low value work task for a single worker–it will probably be placed at the end of the priority list. All too often, IT professionals do get engaged on performing ‘favors’ for people. In those cases, the high value work gets delayed. The justification is always the same, “This won’t take you much time.” But when you get enough of those items lumped together, it does take a lot of time.

A key to agile transformations is to reinvent the IT silos and turn them onto their sides to create capability pipelines. Deliver the tooling and training to allow the individual knowledge worker to quickly build the types of automatedprocesses they need. IT needs to move away from being a supporting activity in the strategy and transformation value chain to being an enabling activity in the value chain.

Being Productive vs Being Busy

Being productive is different than being busy — in life and in business. Identifying value-added activities versus value-subtractive or value-neutral activities is a key first step. Then, like this article discusses, just because it is a value-added activity – the order of those activities make a difference too.  

Manage Latency Changes Between Cloud Regions

After living over twenty years in Tornado Alley, USA, I have learned one important lesson.  Bad things can happen at the edges of clouds.  Cloud edges are where the destructive power of straight-line winds and tornadoes wreak their havoc.  In an IT, multi-cloud migration strategy, those cloud edges can likewise be very problematic.  When you need to get data from one cloud region to another, the strategy that you employ has consequences.  For example, how does the strategy allow you to manage latency changes between cloud regions? The consequences you will need to deal with can affect your stability as well as your cost profile. 

When implementing a cloud migration strategy, most IT disciplines focus on the inside of a cloud region. As a messaging and integration architect, the focus is different.  The sad part is that the cross-region integration ends up getting neglected and, most likely, will be devoid of the necessary engineering constructs to ensure stability and security.  By ignoring that integration, you could also end up causing additional spending on computing resources when you least need to increase your expenses.  As a messaging architect for a multi-cloud deployment, my concern is on moving data from one cloud region or one cloud provider to another.  Moving data inside a region or zone almost becomes inconsequential.  The reason is that the risk profiles facing intra-region communications are vastly lower than inter-region communications. 

The Prevalent Approach

A prevalent approach that is used in cloud deployments is to leverage HTTP as a transport to move messages from one cloud region to another.  In its purest form, an application in region A executes a REST service provided by an application in region B. To ensure that the application in region A has sufficient capacity to handle its incoming requests, the capacity plan for the application in region A needs to account for, not only, the processing time for the application in region B, but also the round-trip network latency to get the messages from region A to region B and back. 

A screenshot of a social media post

Description automatically generated
Prevalent Approach without Messaging

In a previous blog post, I discussed some of the ‘hard things’ that must be dealt with when moving mission-critical workloads to the cloud.  One of those items is the networking between the cloud regions.  If your capacity plan for the application in region A assumes a 15 ms latency between regions A & B, what happens when the latency jumps from 15 ms to 60+ms due to a network failover?  In all likelihood, the application in region A will experience thread exhaustion or will spin up enough new instances to handle the workload while overcoming the increase in latency.  What happens in either of those cases?  With thread exhaustion, you most likely will be in an outage, and depending upon your agreements with your customers—you may be paying a penalty.  With the case where additional application instances are created to handle the slowdown, you need to pay for those VMs.  So, in both cases, expenses are increased to deal with something that should be factored into the technical architecture of your system.  The question that needs to be asked is, “How can we manage changes in latency between cloud regions cost-effectively?” 

What’s Need to Better Manage Latency Changes

One answer to that question involves adding another component to the system.  The intent behind adding this new component should include the following:

  1. Provide a mechanism to support nearly identical response times within a cloud region regardless of latency changes between cloud regions
  2. Provide a mechanism to compensate for changes in latency between cloud regions that is encapsulated so that applications running in each cloud region are not affected
  3. Provide a reusable component so that all applications needing inter-cloud region communication will not need to reinvent the wheel. 

So, with this new component, there needs to be a mechanism to overcome changes in latency.  Since the slowdown would occur in the network layer, there isn’t a significant increase in demand for computing resources.  Therefore, spinning up new VMs like you would need to do for handling additional volume, is overkill.  What typically needs to happen, though, is that additional parallel processing needs to occur.  That need for increased parallel processing is what drives people to spin up new VMs when they hadn’t correctly planned their technical architecture for network slowdowns.  When trying to overcome network slowdowns from 15 ms to 60 ms, 80 ms, etc., all that is needed are some new lightweight processing threads to handle the network traffic. 

A More Efficient Approach

One solution to this issue is to deploy IBM MQ into that additional technical architecture component.  Having been around for a few decades, IBM MQ was designed to help overcome the problems of unreliable and high latency networks.  In other words, it’s a perfect fit for inter-cloud region communications. 

With applications connecting to queue managers inside the specific cloud region that they are running, the app to queue manager latency will remain reasonably stable.  When the application puts the outgoing message on a transmit queue, that application thread frees up to either continue processing or to post a read on the reply-to queue.  Either way, those operations should all be completed in a reasonably consistent timeframe.  So, once the application does get that message on the transmit queue, it is up to IBM MQ to get the message to and from the remote cloud region in a reasonable timeframe. 

For this illustration, I’ll be focusing my attention on the functionality that would be available with MQ Clustering.  The reason for that is the dynamic nature of changes that MQ Clustering provides.  The figure below illustrates the addition of the new component in the architecture.

A screenshot of a cell phone

Description automatically generated
Messaging Component Layer

The queue managers in each region both participate in the same MQ cluster.  With this configuration, you’d have one cluster receiver channel definition for each queue manager.  You’d also have a cluster sender channel defined on each queue manager that is pointed to the full cluster repositories (I have not illustrated the full repositories to keep the picture simple).  When communication needs to be established between those queue managers, each queue manager’s cluster receiver channel definition is used to auto-create a cluster sender channel from one of these queue managers to the other. 

Running Parallel Channel Instances

This approach provides you two different methods to overcome increased latency.  The first is to create additional cluster receiver channels on each queue manager.  Assume that the initial cluster receiver channel is defined with the name TO.QMA.CLUSTERA.  You can copy that channel definition to create TO.QMA.CLUSTERA.1, TO.QMA.CLUSTERA.2.  As soon as they are created and replicated to the repositories, they are started up and start transferring data.  With the appropriate monitoring in place, the definition of these new channels can be handled via automation.  You could end up with a configuration similar to the figure below.

A screenshot of a cell phone

Description automatically generated
Adaptable Messaging Layer

Compressing Message Payloads

The other option can be used either independently from, or in conjunction with, creating additional channel definitions.  The other option is message compression.  Compressing message payloads takes time, so it is something that you want to avoid unless it is needed.  When latency increases drastically, it usually is a sign that compression may help.  When selecting a compression algorithm, you should consider ZLIBFAST because it does provide a reasonably effective compression ratio at a reasonable cost.  RLE is another option, but its effectiveness is highly dependent upon the data being compressed. 

With both of these options, the key takeaway is that by putting the right architecture in place, you would be better able to deal with the inevitable need to manage latency changes between cloud regions. The use of IBM MQ as an illustration for solving the issue discussed in this article was also intended to show that we have some solutions already available for the daunting task of moving some of the rest of the 80% of corporate workloads to the cloud. 

If you would be interested in discussing your specific cloud migration project, please reach out via the form on my Services page. 

Workloads To The Cloud – Mission Critical Systems

While attending IBM’s Think 2020 Digital Experience, I heard from both IBM and Accenture that companies had only migrated 20% of workloads to the cloud.  What I then heard from them caught my attention – “The hard stuff is what is next.” 

The “hard stuff” that they referred to are the mission-critical applications that keep companies up and running.  One thing that I learned during my tenure in IT Operations is that not all systems are created equal.  While a severity one outage with a mission-critical application captures the attention of the entire operations staff as well as several layers of management, no one may even notice a lower-ranked system is down.  I’ve heard of multiple incidents where a member of an infrastructure team had to inform a support team that their application had been down for multiple weeks (or longer).  With a mission-critical application, your customers notify you that your system is down if you don’t already know.   So, when IBM and Accenture say that “the hard stuff is what is next”—this is going to get interesting!

What is the “Hard Stuff” in moving workloads to the cloud

When designing a messaging solution for a mission-critical application, you need to address some fundamental concerns.  Those concerns include latency tolerance, data sequencing affinity, data loss tolerance, data security, throughput requirements, and data duplication tolerance.  When the complexity of a hybrid, multi-cloud migration gets added to the equation, the difficulty in resolving those factors increases dramatically. 

Hard Stuff:  Increased number of dependencies

Once you leave the confines of a single data center deployment, new headaches emerge as you become more dependent upon other parties.  For example, one company where I worked utilized two physical data centers with a 13-millisecond network latency.  By adding that technical requirement, we not only added a dependency on the telco providing the networking service, but we also added a dependency on whichever construction company or governmental agency was working on the roadways or railways where the fiber had been laid.  Whenever there was a fiber cut, we needed to switch over to the backup route, which had a latency of 80-milliseconds.  With the performance of TCP degrading rapidly over high latency, utilizing the backup network route was similar to completely losing that second data center. 

Hard Stuff:  New characteristics of the cloud

Now, when you add to the equation the dynamic nature of cloud providers, some of that “hard stuff” comes into a more unobstructed view.  In the cloud, virtual machines may just go away, for example.  If something like that happened in a private data center, the compute support team would be spending sleepless nights making sure it never happens again.  When your compute is in the cloud, and you lose a virtual machine, the most you are expected to say is, “Oh.” 

When moving mission-critical workloads to the cloud and having to deal with an intolerance for increased latency, ensuring data sequence is maintained, and also ensuring that data is secure from eavesdropping, yeah, that’s hard—but it isn’t impossible. 

While cloud-based integration is different than on-premise, monolithic application integration, there are still some concepts that we utilize in messaging from on-premise deployments that are key to a successful deployment in the cloud. While addressing the new aspects of cloud-based integration, I suggest you rely upon those concepts as your anchor point from which to work.  Those concepts are service orientation, dynamic routing, and continuous availability.

Service Orientation versus Location Orientation

You are most likely in trouble when you are having discussions about which specific cloud region where an application needs to direct messages for its downstream services.  The reason is that the upstream application shouldn’t know where its dependencies are currently running.  If each upstream application has that awareness, failing a service from one region to another would require a significant amount of coordination.  Alternatively, a centralized operations control staff would need to be aware of any primary, secondary, and tertiary locations for each service so that in the event of an outage in the primary site, they can redirect the message flow.  Neither of those options is ideal because they most likely involve configuration changes. 

Ideally, the location of the primary, secondary and tertiary sites for each service is isolated from the application calling the service.  Also, while a centralized operations staff should have visibility to where services are running and be able to take specific services down when necessary, their involvement should be minimal to avoid redirecting messages to the incorrect location.  When using a transport technology such as IBM MQ, the sending application writes a message to a queue.  Where the message ends up is irrelevant as long as it gets processed according to the Operational Level Agreement.  The architectural goal is to maintain existing configurations, but to have a method of redirecting traffic away from specific instances or regions. 

Dynamic Message Routing

Once a requesting application sends a message, there needs to be a dynamic routing ability to get the messages to the correct service wherever that service is currently running.  The driver for this may take on many different forms.  Due to data sovereignty laws, the infrastructure may need to route certain data to specific locations.  Also, due to how a company may segment its customer base among different cloud regions due to latency sensitivities, the data may need to pass through a content-based routing solution typically included in an enterprise service bus.  Those are the kinds of issues that surface on a day-in-day-out basis.  Also, there is the need to dynamically re-route messages to support regular operations.  There is also the need to handle outages of either a single service or for an entire cloud region. 

Continuous Availability

While integrating legacy, monolithic applications typically involve designing applications to be highly available and, at times, to have disaster recovery plans so that support teams can restore a service within days, the concept still exists in the cloud. But it has been taken up a notch (or several notches).  There is an expectation that applications running in the cloud are continuously available.  Fulfilling that expectation can take on a few different forms.  The first is that several instances of the application are running in parallel in multiple cloud regions.  In that case, the infrastructure would need to distribute the transaction load to all running instances.  In another case, an application instance in one specific region is taking all the transaction load, and instances that exist in the other areas serve as standby/failover instances.  

Redundancy Approaches

The first case is one that is probably most familiar to people.  There is a load balancer in front of different application instances running in different cloud regions.  As a message comes into the load balancer, the load balancer determines the next application instance to send a message to and off it goes.  That’s fine as long as that application’s processing time is relatively uniform.  Otherwise, the load balancer may forward a message to an instance that doesn’t have any threads available.  Most companies wouldn’t necessarily have that issue, but in very high transaction count companies with a wide variance in processing times–it can be a problem. 

The most challenging situation involves applications with message affinities that are primary in one cloud region but are running standby instances in the other areas.  Two things need to occur.  First, messages need to be routable to both the primary and secondary locations within a reasonable amount of latency.  That need is so the infrastructure can assure that messages can be received at the appropriate endpoint regardless of which one is active.  Second, the infrastructure needs to replicate messages delivered to the primary instance to the secondary instance.  By taking those two steps, the infrastructure can resolve the affinities.

Redundancy Levels

With both of these scenarios, there should be two levels of redundancy.  The first is that sufficient capacity should exist within a specific region to tolerate some instability.  From a messaging standpoint, there should be sufficient IBM MQ queue managers within a particular region to allow for some of them to be down for maintenance, and the applications using those queue managers should not be alarmed by that state.  The second level is when an administrative action is issued to take down an entire region.  There should be at least one other entire region available to process the transaction load.  The case where there are message affinities is more sensitive and needs to be done in a coordinated effort – hopefully via automation.  In both cases, though, the intent should be to perform those region-level failovers without impact to your customers. 

Working with Application Architects when moving workloads to the cloud

While application architects can be very knowledgeable about the technical architecture they have worked with on-premise, their knowledge may not translate to cloud-based deployments when moving workloads to the cloud. While I focused this article on messaging, there are other aspects application architects must consider.  To assist them in designing their overall approaches, you, as a messaging architect, should allocate time to educate the application architects on how the technical architecture changes as part of a cloud migration.

Moving a company’s “bread and butter” systems to the cloud is something that shouldn’t be taken lightly.  However, it isn’t impossible.  By building upon experience gained in performing integration on-premise and then adding the lessons learned in moving non-critical workloads to the cloud, you have a good foundation.