Article Archives - magic beans

The Cloud Delusion: Why Your “Transformation” is Just an Expensive Data Center Relocation

Joana Alves — Mon, 13 Apr 2026 13:33:46 +0000

By Vitor Rodrigues (Magic Beans CEO)

Most companies are not “in the cloud”; they are merely “renting someone else’s computer” to run 20-year-old mistakes. The promised land of agility, cost savings, and innovation has turned into a graveyard of lift-and-shift projects and spiraling monthly invoices.

The reason? Too many organizations stay in their comfort zones. To truly harness the cloud, leaders must stop treating it as a technical destination and start treating it as a fundamental rewrite of the corporate operating model. If you aren’t ready to do the “hard stuff” — refactoring core systems, breaking vendor lock-in, and asserting data sovereignty — you aren’t transforming. You’re just changing your billing address.

The Comfort Zone Trap: The “Lift and Shift” Lie

The biggest mistake enterprises make is choosing the path of least resistance. They take a legacy monolithic application, wrap it in a virtual machine, and drop it into AWS or Azure or GCP.

The result? You now have a legacy monolith that is more expensive to run, harder to monitor, and just as rigid as it was on-prem.

True cloud success requires refactoring. It requires the painful work of breaking down monoliths into microservices. If your “cloud-first” strategy doesn’t involve your developers sweating over architecture, you aren’t doing it right. You are simply paying a premium for the privilege of not having to manage hardware.

The Great Provider Trap: Lock-in is the New Legacy

Cloud providers are the new “Big Blue.” They want to wrap you in a warm blanket of proprietary services — serverless functions, DBaaS, and AI tools that only work on their backbone.

The moment you build your core business logic into a provider-specific tool, you have surrendered your leverage. You are locked in for the next decade.

The hard truth: you must architect for portability. Your core systems should be “cloud-agnostic” by design. This means:

Using containers (Kubernetes) as the universal deployment language.
Abstracting your data layer so it can be moved between clouds.
Maintaining a contingency plan to bring workloads back on-prem. If the economics of the cloud shift—and they will—you must have the technical capability to pull your core workloads back to your own private infrastructure without a three-year migration project.

The Operating Model Crisis: You Can’t Run a Tesla with a Steam Engine Team

You cannot manage a 2026 cloud environment with a 2005 IT organization.

Most companies keep their “Infrastructure Team” and their “Dev Team” in separate silos, then wonder why their cloud costs are 40% over budget. The cloud requires a paradigm shift in talent:

From Project to Product: Stop funding “projects” with end dates. Cloud systems are living products that require continuous optimization.
FinOps is not optional: In the data center, costs were a CAPEX discussion once every five years. In the cloud, every line of code is a financial decision. If your engineers don’t understand the cost of a SELECT * query, you are bleeding money.
Partner Sourcing: Stop hiring “body shop” partners who charge by the hour. You need partners who are incentivized by your efficiency, not your headcount. If your partner isn’t trying to automate themselves out of a job, they are the wrong partner.

Sovereignty and the Hard Decisions

The “hard stuff” involves looking at your core ERP or core banking system and admitting that it cannot run in a public cloud in its current state.

Sovereignty isn’t just about where the data sits; it’s about who controls the keys.

Encryption: If the cloud provider holds the keys, they have the power.
Compliance: In a world of shifting geopolitics, a CIO who cannot move critical workloads from a US-based cloud to a European-based sovereign cloud in 48 hours is a liability to the board.

Conclusion: The Call to Action

The “comfort zone” is where digital transformation goes to die. To the CIOs reading this: stop asking your teams for a “cloud migration plan.” Ask them for a “cloud-native operating model.”

Stop the lift and shift.
Start the refactor.
Break provider lock-in.

The cloud is an incredible tool for those brave enough to rebuild their foundations. For the rest, it’s just a very expensive way to stay exactly where you are.

The post The Cloud Delusion: Why Your “Transformation” is Just an Expensive Data Center Relocation appeared first on magic beans.

Multicloud… Oops! It was an accident

Rui Ribeiro — Thu, 15 Jun 2023 18:40:03 +0000

When I see how the #multicloud adoption global figures are raising every year, I wonder if this is happening by design of by accident. Probably the origin of #multicloud in many organizations was combination of both factors, but nowadays many organizations are making their #multicloud choice consciously. In any case, #multicloud is the reality that we see in the market today because offers many benefits and opportunities. But also, it brings challenges that we must understand and manage.

To avoid misunderstandings, let’s begin with some basic definitions. #Multicloud is the usage of Cloud computing services from more than one Public Cloud Service Provider (CSP) for different workloads. While hybrid-cloud is when we are running our different workloads on both Public Cloud Services Providers, Private Clouds, edge computing and on-premises. This is the on-going situation of the organizations that are in a Public Cloud adoption journey. And finally Distributed Cloud is when we can run our workloads on different computing machines hosted on different CSPs, Private Clouds or on-premises data centers. Cloud is centralized by definition, but it’s also distributed among the Edge, different regions and availability zones. We’ll center the focus on #multicloud on this article.

Having “multi-IT-suppliers” is not new. We have dealt with that situation for decades. And we reached this situation also from a combination of strategic decisions and some tactical ones.
The strategic decisions came from the standardization of preferred supplier, or suppliers, for each category, such: hardware, operating systems, database management systems, development environments, identity management, etc. These strategic suppliers map usually found a balance among capabilities and cost, with the aim of avoiding vendors lock-in.
The tactical ones usually came from acquisitions from end-users in the departments. These tactical decisions could be made with the involvement of IT or without them –what we called shadow-IT. This could also happen on the Cloud world.

In any case, we were used to manage a “multi-IT-supplier” reality, keeping a consistent corporate architecture, using different solutions for data and applications integration, having a federated identity management, common security procedures and tools, business continuity, etc.

This is a good experience to start with, but as we know, in the Cloud there are some additional considerations to deal with.

Show me your workloads, and I will tell you… When we analyze the cloud workloads that are supporting our business, we can identify four main types (simplifying…):

1. Cloud native workloads: workloads designed to run in a specific CSP, using their Cloud native services, architected to get all the benefits of the Cloud. Despite these workloads could be migrated to other CSP with relative low effort, the decision of using unique proprietary services of a CSP has pros and cons that we should understand.

2. #multicloud native workloads: they are also cloud-native workloads, but designed to run in any CSP, taking full benefits from a #multicloud deployment. For example, running a single Kubernetes cluster with multiple nodes deployed on different CSPs. If you have these kinds of workloads is probably because you have a #multicloud strategy in your organization. And you want to ensure that every new development follows the necessary standards to guarantee the deployment across CSPs without compromises.

Types 1 and 2 could come either from brand new developments –greenfield innovation taking advantages of Cloud new possibilities–, or from the deep rearchitecture of legacy applications –Brownfield innovation–.

3. Legacy workloads: bespoke or packaged on-premises workloads that we lifted and shifted into a CSP Virtual Machine without big changes. If these workloads are running on any base software, such Database Management Systems, we should make it available on the CSP of choice. This availability could condition the decision of the CSP, and maybe could be against our strategic choices.

Types 1 & 3 could run on a specific CSP by accident as a consequence of a tactical move, or because we were forced by the software dependencies, as we have commented on the Type 3. Or can be by design, based on a conscious decision. For example, of the typology of the workload to take advantage of each CSP’s unique offering. You could have decided, for example, to run all analytics workloads on Google Cloud, Development/DevOps workloads on Azure, Web Content on AWS, or Database workloads on Oracle Cloud Infrastructure. This conscious decision can also be taken for other reasons as: the location of the CSP datacenters and access points, availability of services, how critical is the workload, price/performance considerations, scalability, elasticity, security, certifications of the CSPs, or sustainability.

4. SaaS workloads: third party applications which we usually get by subscription, that are hosted on the CSP of choice of the SaaS supplier. In general, the CSP deployment details are transparent for the end user. Therefore, if we are consuming different SaaS applications, that is the case of most of the organizations today, we are potentially enjoying a #multicloud experience without notice.

For this reason, when it comes to the selection of a new SaaS application, it's highly recommended that the end-user and the IT department work together to consider, not only the functional fit, but also the technical fit with the organization standards. It’s important to analyze together the hidden implications of the decision, taking into consideration factors as: performance, integration, security and cost.

Key benefits of a #multicloud strategy

1. Flexibility and CSP independence:one of the main benefits of #multicloud adoption is flexibility. By distributing workloads among multiple cloud platforms, organizations could gain independence from any single CSP. Reducing the risk of vendor lock-in and empowering organizations to leverage the best-of-breed services from different providers. Additionally, it provides the freedom to switch between providers or negotiate better terms, ensuring competitive pricing and improved service levels. This is not new; it was also the strategy of many organizations in the on-premises era.

2. Optimized performance and scalability: as we have pointed out above, each CSP excels in different aspects. With a #multicloud approach, organizations can select the most suitable provider for each workload, tailoring their choices based on specific performance requirements. This ensures optimal performance, scalability, and responsiveness, as workloads can be allocated to the most suitable CSP based on their unique characteristics.

3. Better resilience and reliability: #multicloud inherently provides enhanced resilience and reliability. By diversifying infrastructure across multiple CSPs, organizations can minimize the risk of downtime due to provider outages or system failures. Workloads can be seamlessly shifted between clouds, if they are designed for that purpose (Type 2), ensuring continuity of operations and minimizing the impact of any single point of failure. This redundancy significantly improves overall system reliability and helps maintain business continuity.

4. Increased security and compliance:#multicloud offers the potential to enhance security and compliance measures. By distributing workloads across multiple cloud providers, organizations can implement defense-in-depth strategies, mitigating the risk of a single point of failure. Additionally, using multiple CSPs allows organizations to choose platforms with different security features and certifications, ensuring adherence to industry-specific compliance requirements. Here is important to remark that choosing the right CSPs, as not all the cloud providers have the same security level or comply with the same certifications.

Considerations of a #multicloud strategy

Having a #multicloud strategy has strong benefits as we have seen, but it also brings some challenges that we need to understand and manage to get a successful implementation. Let’s discuss some challenges and what are the best practices to deal with them.

1. Effective Cloud management: managing multiple cloud platforms requires robust cloud management practices and the availability of specialized talent.

Adopting a centralized management approach with comprehensive monitoring, automation, and orchestration capabilities can streamline operations, optimize resource allocation, reduce costs, and simplify governance across all CSPs. In addition, we should implement centers of excellence for each of the CSPs to support the central management group and give advice to the different project teams.

If we don’t have the necessary talent in-house. We can contract a #multicloud #ManagedServices provider to complement us. Partnering with the right company will get good payback.

2. Interoperability, integration, and portability: ensuring seamless interoperability and integration between different cloud platforms is crucial. Organizations should invest in standardizing APIs, leveraging containerization technologies like Kubernetes, and utilizing integration frameworks to facilitate smooth data flow and application portability across CSPs.

These elements are not new, as we have commented above, they also were key on the on-premises world when we had a multi-IT-suppliers strategy. The difference with Cloud is that we must take into consideration other elements, as the network’s interconnection among CSPs and the latency. There are alliances between some of the main CSPs to interconnect their datacenters. This could simplify our life.

We should consider also the “Data gravity” aspect. Data has a “mass”, and therefore moving a huge amount of data around is not feasible. Especially if we have real time needs. It takes time, what impact performance, and could imply high costs. Maybe it’s easier to approach the applications to the place where most data are located, and not the opposite.

3. Data governance and security: keeping data governance and security in a #multicloud environment is key. Implementing principle of least privilege, consistent data encryption, access controls, and security protocols across all CSPs is essential. Implementing regular audits and risk assessments should be conducted to identify potential vulnerabilities and ensure compliance with relevant regulations.

If we don’t have the right resources in-house, we can always subscribe to a #multicloud posture management service to complement us.

4. Vendor management and cost optimization:: and last but not least, managing relationships with multiple cloud providers requires effective vendor management strategies. We should negotiate favorable contracts, optimize costs through workload placement, and regularly review provider performance to ensure they are meeting service-level agreements.

Something critical to consider are the “exit barriers”. Please carefully look at the data-egress fees of the different CSPs. There are important differences among them. This cost could potentially kill our #multicloud strategy, or at least condition it. Ensure that you discuss that angle when it comes to negotiating with your CSPs of choice.

Additionally put in place a Cloud Financial Management (CFM) practice in your organization – something beyond traditional FinOps. CFM will help you to be in control of your cloud spend, reduce waste, and ensure that you're optimizing your resources and investments in the cloud. The CFM practice involves budgeting, cost optimization, forecasting, and cloud cost management. This will require collaboration across many departments including IT, finance, and operations. CFM is also very important when you have a single-cloud strategy.

Conclusion

#multicloud is the strategy of many organizations today, seeking to optimize their Cloud operations and leverage the strengths of multiple CSPs. They get more flexibility, independency, resilience, and performance. However, a successful implementation requires understanding well the implications, we should put in place a realistic plan, implement strong #multicloud management practices, and a deal with interoperability, latencies, “data gravity”, security, and cost optimization. Ensure that #multicloud is not happening just by accident.
To be successful on #multicloud, probably talent is the key ingredient. Consider partnering with a #multicloud #ManagedServices provider, it will bring peace of mind.

by Félix del Barrio
Technology and Business Senior Advisor
24-5-2023

The post Multicloud… Oops! It was an accident appeared first on magic beans.

Application Migration Service General Description

Rui Ribeiro — Thu, 02 Mar 2023 17:21:19 +0000

Why use Application Migration Service when migrating to the Cloud?

AWS Application Migration Service is a tool that helps customers migrate their applications to the cloud by automating much of the migration process. This service is designed to make it easy for organizations to move their existing applications to the cloud without having to spend significant amounts of time or resources on manual migration tasks.

One of the key benefits of AWS Application Migration Service is that it supports a wide range of applications, including web applications, batch processing applications, and databases. This makes it a versatile tool that can be used for a variety of migration scenarios.

Some key features and benefits of AWS Application Migration Service:

Automated Migration: AWS Application Migration Service automates many of the tasks involved in migrating applications to the cloud. This reduces the amount of time and resources required to complete the migration and minimizes the risk of errors or issues during the process.
Compatibility: The service is compatible with a wide range of applications and operating systems, including Windows, Linux, and Unix. This allows organizations to migrate their applications regardless of the underlying technology stack.
Scalability: AWS Application Migration Service is designed to handle large-scale migrations, making it suitable for organizations with large and complex application environments.
Flexibility: The service supports a variety of migration strategies, including lift-and-shift, replatforming, and refactoring. This allows organizations to choose the approach that best suits their needs and objectives.
Security: AWS Application Migration Service is built on AWS, which has robust security features and compliance certifications. This ensures that organizations can migrate their applications to the cloud with confidence, knowing that their data is secure.

Overall, AWS Application Migration Service is a powerful tool that can help organizations accelerate their journey to the cloud. By automating much of the migration process and supporting a wide range of applications, this service makes it easier and more cost-effective to migrate to AWS.

Deployment Overview

In order to use Application Migration Service, the first step is to create a template that will guide all configuration aspects of the migration, from the type of instance to use in the AWS environment, the network where is going to be allocated, the restrictions in bandwidth to use during the migration (if needed), etc. After that, the source servers are added by installing the AWS Replication Agent on each individual server. As the agents are installed the migration starts and can be monitored in the AWS console.

A representation of a general schema of the application and a representation of the different elements involved in the process can be seen above in Figure 1.

Before launching the migrated instances in a production environment, these instances are migrated to a Staging Area in order to perform tests and make sure the applications behave as expected. After all tests are performed and the applications are running as expected the final stage of this process is the Cutover phase where the on-premises server can be turned off and the instance in the AWS environment is put in production.

This migration process is very useful, especially in situations where a server might contain several services running and there’s a lack of documentation about said services or dependencies. These cases can be easily bypassed as Application Migration Service migrates the actual state of the server (operating system included).

After the migration is concluded, and as long as the server is running, all alterations made in the source server are replicated to the instance in the Staging Area in order to have the most updated version upon Cutover.

AWS Application Migration Service helps users manage their migration by grouping Source servers and Applications in Waves if there are dependencies among applications. These are logical groups, describing the migration plan over time.

It’s possible to:

Monitor the wave’s migration status, progress, and associated applications
Perform operations on the wave, such as editing, tagging, and archiving
Perform bulk operations on the applications associated with the wave

Summary

AWS Application Migration Service (MGN) is a highly automated lift-and-shift (rehost) solution that simplifies, expedites, and reduces the cost of migrating applications to AWS. It allows companies to lift-and-shift a large number of physical, virtual, or cloud servers without compatibility issues, performance disruption, or long cutover windows. MGN replicates source servers into your AWS account. When you’re ready, it automatically converts and launches your servers on AWS so you can quickly benefit from the cost savings, productivity, resilience, and agility of the Cloud. Once your applications are running on AWS, you can leverage AWS services and capabilities to quickly and easily replatform or refactor those applications – which makes lift-and-shift a fast route to modernization.

The post Application Migration Service General Description appeared first on magic beans.

Migrating Websites To S3

Rui Ribeiro — Thu, 02 Feb 2023 14:17:39 +0000

For the majority of organizations intending to move to the cloud, their webpages and webapps are of the utmost importance, since they are, in most cases, the organization’s store front to the world and the interface through which the customers and potential customers interact with the services provided by the organization. Therefore, special attention should be given to the migration of such components so that they are able to take full advantage of all the facilities AWS provides in order to guarantee the best experience for the users while also improving the performance, scalability, and security of the website.

Taking this into account, at Magic Beans, we propose to our customers to migrate their webpages (whenever possible) to a S3 and CloudFront solution, instead of migrating their on-prem webserver as-is to their new AWS environment.

Why use AWS S3 for website hosting?

AWS S3 is a highly scalable and durable storage solution that can help you store, serve, and protect your website content. AWS S3 website hosting allows users to store their web pages and other content in S3 buckets.

One of the primary advantages of AWS S3 is its scalability. AWS S3 can handle an unlimited amount of data, making it an ideal platform for storing and serving website content. This means that as the website traffic grows, S3 infrastructure will handle the additional load without worrying about capacity limitations.

Cost is also a big advantage of S3 website hosting. This way the customer only pays for the amount of storage and the amount of bandwidth used. This means that there’s no webserver cost and the customer only ends up paying for actual usage, which translates to considerable savings compared to hosting on a traditional webserver.

AWS S3 is also a highly available service by default, ensuring that the website is always running, even in the event of infrastructure failure on AWS’ side, removing the need for a Disaster Recovery plan and solution. In addition to all of the points above, AWS S3 also offers robust security features, including encryption at rest and in transit, access control, and data compliance. This helps to protect your website from unauthorized access, data breaches, and other security threats.

Integration with CloudFront

Amazon CloudFront is a content delivery network (CDN) service that speeds up the distribution of static and dynamic web content.

Integration between AWS CloudFront and S3 allows for the use of CloudFront as a CDN to distribute the website stored in S3 to users globally, with low latency and high transfer speeds. This integration helps improve the performance of the website or application and reduce your overall content delivery costs.

To achieve this, CloudFront uses AWS’ Edge Location network to cache the website. This way, users can access the website with minimal latency.

CloudFront also provides real-time metrics and logs to help monitor and troubleshoot delivery issues, as well as understanding trends in the access to the website.

Deployment and management

Deploying this solution is also a much simpler setup than a traditional infrastructure. One only needs a S3 bucket with website hosting enabled and a CloudFront distribution that points to the bucket in question. A simple example can be seen below in Figure 1.

To manage and update the website contents, it is only required to update the source files that are inside the S3 bucket. This task can be achieved by using the AWS Console, the CLI or the SDK. This allows the user to do the updating manually in a web interface or have the freedom to automate the process however they like, for example, integrating this step in a CI/CD pipeline.

Below is an example of the same website architecture where the website code stored in the S3 bucket is updated by a pipeline from CodePipeline that is triggered by changes in a git repository. With this architecture we have a fully automated website deployment model that is compliant with modern DevOps practices and cloud-native philosophy.

Summary

By making the change to this hosting and distribution model, the organization eliminates virtually any need for infrastructure management regarding the website, no matter the scale of their project, or the demand spikes one might have to consider when managing a typical webserver infrastructure. Furthermore, by taking advantage of AWS’ worldwide infrastructure network, one can achieve levels resiliency and performance that are nearly impossible to achieve in a traditional solution.

By implementing such a solution, the organization can expect a much more resilient website, as well as the best performance available in the market and a reduced cost compared to a more traditional solution, all while being elastic in order to adapt to the real world demand.

This makes it, in our opinion the best solution to deploy a website, and that’s why we are so adamant in recommending it to our customers when they come to us to help them kickstart their cloud journey. In our eyes, deploying a website in S3 and CloudFront is the perfect example of a cloud-native solution.

The post Migrating Websites To S3 appeared first on magic beans.

Why do I need a MSP?

Rui Ribeiro — Mon, 10 Jan 2022 13:15:13 +0000

At the beginning of your cloud journey, or at a given point of that journey, you may ask yourself a number of questions, that go from “How do I migrate my workloads to a public cloud?”, or “How do I optimize my spending in a public cloud?” to “How do I manage my workloads in a public cloud?”. In searching the answers to those questions, and much more, you find the answer to a simpler, but much broader question: “Why do I need a Managed Services Provider?”

Being a next-gen AWS MSP is first and foremost being focused on the client: the clients’ needs are key! And to care for the clients’ needs means that we at Magic Beans are committed to three pillars:

Educate customers: on a proactive, ongoing basis, offering consultative and advisory services. The relation with client must be of a trusted advisor, and not of someone that is only present when something is broken and needs to be fixed. By being proactive in our communication with the client we try to prevent failure and lead the client in the right direction.
Lead with AWS Professional Services: by having the required talent and know-how. From day one of the relationship with the client we establish ourselves as experts, by having talented people with extensive training and years of experience in AWS. Training is a core part of our daily routines and a continuous process that we see not as a goal on itself, but as the mean to establish ourselves as experts in the matter, and to provide services accordingly.
Advocate to customers: the use of and evolution of AWS offers. As experts we pride ourselves on being always watchful for the evolution of AWS services, and finding a match between that evolution and the search for the “right tool for the job”. The constant evolution of AWS offers means so that clients can find new paths to deliver their workloads in a more optimized manner.

When you consider the burden of migrating your entire workloads to a public cloud it may seem overwhelming, not only the process itself, but the planning and the architecting that must be made in order to guarantee a successful migration. As a MSP Magic Beans can assist you in that process by leveraging the AWS Professional Services to help you define the architecture and the process, demystifying any preconceptions of complexity or lack of security that sometimes are associated with migrating to public clouds.

Having a MSP by your side is the best guarantee of a seamless and pain-free migration. But Magic Beans can do more: from the start of your cloud journey it is very important to consider the various services that AWS provides, as those bare the major benefits of this journey. Magic Beans can help you identify which can be leveraged to end with a more robust and optimized solution that you had on-prem.

But maintaining and managing an AWS infrastructure is a different challenge, one with a very different approach in comparison with on-prem. Again, AWS and Magic Beans have the tools and the know-how to make that a much smoother process, while being less time consuming. At Magic Beans we use industry leading monitoring tools to keep a watchful eye and guarantee that any event in your AWS environment is noticed, registered, and acted upon, if necessary. Events that require an action are, whenever possible, dealt with by using DevOps practices, always with an emphasis on automation, and self-healing infrastructures.

Automation is paramount in responding to events, as it represents the faster way to act upon those events, but only if compared to a more manual approach. At Magic Beans we try to be even faster, and to accomplish that we rely in predictive tools that help us decode tendencies and act even before potentially disrupting events occur, setting the trend towards a preventive approach and away from a reactive one.

If you already began you cloud journey and are looking to optimize your spending, Magic Beans, as an next generation MSP, is prepared to partner with you and make a thorough analysis of your cloud environment and recommendations and implement the changes necessary to optimize your spending, always keeping in mind the requisites for a robust and streamlined operation. At Magic Beans we believe our experience and training are invaluable tools, and every client is an opportunity. Training gives us the foundations but only sharing clients’ challenges can give you the insight needed to identify focal points that can contribute to large gains in performance and/or cost optimization.

In a fast paced world, where changes are a constant and performance is nothing without reliability and optimization, what you need to leverage the competitive advantages public cloud and specifically AWS can give you, is a solid partner that can help you focus on your business, instead of spending resources on implementing, managing and maintaining a tool (or toolset) for which you are not trained, experienced, or keen on exploring. We, at Magic Beans are that partner. And we are eager to show you that the real question is: How can you do without an MSP?

The post Why do I need a MSP? appeared first on magic beans.