The first one was filed on November 19, 2017. Seven years ago. The ask: let an admin change a customer’s email address in Jira Service Management. Not migrate accounts through a four-step workaround involving Atlassian ID. Just… change an email address. The kind of thing you’d expect a junior developer to ship on a Tuesday afternoon. As of today, it has 779 votes, 447 watchers, and a status of “Future Consideration.” Which, in SaaS-speak, translates roughly to: “we heard you, we filed it, please stop asking.”

The second one landed in January 2019. The request: make Confluence’s alphabetical page sorting persistent, so new pages don’t just pile up at the bottom like uninvited guests. Six years later: 600 votes, 261 watchers, status “Under Consideration.” Progress!

Now, to be fair to Atlassian, they’re not uniquely terrible. Every major SaaS vendor has a graveyard of feature requests exactly like these. Sensible, obvious, clearly wanted by thousands of paying customers. Just… never quite prioritized. Because they have a roadmap. And you’re not on it.

This is the part of the SaaS brochure they don’t show you.

The Pitch vs. The Reality

SaaS vendors are exceptionally good at one thing before you sign: making you feel like you’re about to get exactly what you need. The demos are polished. The slide decks are beautiful. The onboarding is smooth. Eighty percent of your requirements? Covered, on day one.

It’s that remaining twenty percent where things get interesting.

That twenty percent is where your actual workflows live. The edge cases. The things specific to how your organization actually operates. And when you file a support ticket asking about them, you enter a fascinating parallel universe where time moves differently. Features are “on the roadmap.” Updates will come “in a future release.” Your vote has been registered. Thank you for your feedback.

Meanwhile, you’re paying. Every month. For the product as it exists, not as it was promised.

The Numbers Are Telling

The scale of SaaS sprawl is difficult to overstate. According to BetterCloud’s annual State of SaaSOps report, the average number of SaaS applications per company peaked at 130 in 2022 and even after a wave of consolidation, still sits at over 100 today. That’s more than 100 subscriptions to manage, renew, secure, and integrate. For every single organization.

The waste embedded in that sprawl is just as striking. Gartner estimates that approximately 30% of purchased SaaS licenses go unused, what they bluntly call “toxic spend.” BetterCloud puts a price tag on it: companies report wasting an average of more than $135,000 per year on unused software licenses alone. And Gartner projects SaaS spending will continue growing at around 19% annually, reliably outpacing the budgets meant to fund it.

Do the arithmetic on a typical mid-market tool. Fifty users. €50 per user per month. That’s €30,000 per year. Every year. With annual price increases that arrive in your renewal email as a polite fait accompli. After five years, you’ve spent €150,000-plus on software you don’t own, can’t modify, and can’t easily leave and somewhere between a quarter and a third of those licenses have been sitting idle.

Something Changed

Here’s what’s different in 2026: building software got dramatically cheaper and faster. Not incrementally but by an order of magnitude.

Tools like Claude Code and Kiro represent a new category of agentic coding assistants. They don’t just suggest the next line. They can take a requirement, reason through a solution, write the code, test it, catch errors, and iterate, with minimal human supervision. What previously required a team of developers and months of work can now be done by one technically capable person in days.

This isn’t science fiction. It’s happening right now in engineering teams across the world.

And it fundamentally changes the math on one of the oldest questions in IT: should we build or buy?

What You Get When You Build Your Own

When you build a custom application -even a relatively simple internal tool- you build exactly what you need. No more, no less. You control the data model, the workflow, the integrations, and the roadmap. And critically: you decide what gets built next. Not a product manager in Sydney who’s never seen your workflows.

Running on cloud-native infrastructure like AWS means scalability, security, and availability are largely handled by the platform. The operational gap between “something you built” and “something a vendor hosts for you” has narrowed considerably. And the cost gap has flipped.

A custom-built equivalent to that €30,000/year SaaS tool, developed with AI-assisted tooling and running on serverless AWS infrastructure, might cost a fraction of that annually in operational expenses, after a one-time build investment that has also come down dramatically. More importantly: you own the asset. It does exactly what you need. And you’re not waiting seven years for someone to let you update an email address.

A Word of Honesty

Custom software isn’t free of responsibility. Someone has to maintain it, secure it, and evolve it. The SaaS argument, that someone else handles the infrastructure, the uptime and the patches, is not without merit. And for commodity functions like email, video conferencing, or payroll, that argument still wins. These are solved problems. Building your own would be an expensive act of reinvention.

But pairing custom-built applications with managed cloud services gives you the operational coverage of SaaS without the product dependency. You get uptime. You get security. You get to decide what comes next.

So What Should You Actually Do?

Not everything should be custom-built. That would be its own kind of madness.

The question worth asking is simpler: where are your core differentiating workflows? The processes that encode years of operational knowledge. The edge cases that keep showing up in feature request threads, yours and everyone else’s, year after year, status unchanged.

Those are exactly the features that will never quite make it onto a SaaS vendor’s roadmap.

The question is no longer “can we afford to build?” The question, in 2026, is whether you can afford to keep waiting.

JSDCLOUD-5746 would like a word.

The post Dear SaaS Vendor, We’ve Been Waiting Since 2017. appeared first on Cloudar.

In the AWS ecosystem, MSPs take vastly different approaches when building customer-specific landing zones and cloud management platforms. Some approaches preserve your freedom and flexibility. Others quietly build the walls of a gilded cage.

The Two Paths: Open Standards vs. Proprietary Platforms

The Open Approach: AWS Landing Zone Accelerator (LZA)

AWS Landing Zone Accelerator represents the gold standard for customer independence. As an open-source solution built on AWS CDK and CloudFormation, we deploy LZA to provide several critical advantages:

• Complete transparency: All infrastructure is defined as code that you can read, understand, and modify
• No licensing fees: Open-source with no proprietary components
• AWS-maintained: Continuously updated by AWS to keep up to date with new services and features
• Industry standard configuration: With multiple documented sample configurations, you do not need to start from scratch.
• Full customer ownership: Deployed directly into your environment with complete access to the Infrastructure as Code
• Exit-ready from day one: If you ever want to manage it yourself or switch MSPs, you own your landing zone configuration

At Cloudar, we’ve built an entire landing zone practice around LZA precisely because we believe customers should never feel trapped. Your AWS foundation should be an asset you own, not a chain that binds you to any single provider.

The Proprietary Approach: Custom Orchestration Platforms

In contrast, many MSPs have developed proprietary cloud management platforms that create significant lock-in. These are often marketed as “revolutionary” or “next-generation” platforms that promise to make cloud management easier with “just a few simple clicks” or web-based portals that abstract away complexity.

The convenience is real. The long-term cost is hidden.

Here’s what proprietary platforms typically involve:

• Black box deployment: Resources are created through proprietary tooling that abstracts away the underlying infrastructure
• Dependency on custom APIs: Your operations become dependent on the MSP’s platform rather than native AWS tools
• Limited portability: Moving to another MSP or bringing management in-house requires re-platforming
• Knowledge gap: Your team never develops deep expertise in AWS native tools because they’re shielded by the abstraction layer
• Commercial leverage: The MSP knows that switching costs are high, affecting pricing negotiations and service quality over time

The Lock-in Mechanisms You Need to Watch For

1. Custom Landing Zones Without Source Code Access

Some MSPs deploy your resources using “their” landing zone—a pre-configured multi-account setup built with proprietary Infrastructure as Code that remains their intellectual property. When you want to leave, you inherit an AWS environment you don’t fully understand, configured by tools you can’t access.

The Cloudar difference: We can deploy LZA directly into your AWS accounts. Every CloudFormation stack, every configuration file, every security baseline—you have access to it all.

2. Web-Based Orchestrators That Become Operational Chokepoints

Fancy web portals that let you “deploy with one click” sound appealing. Until you realize that every operational change must flow through the MSP’s platform. Want to modify a VPC? You’re dependent on their UI. Need to adjust security groups? Better hope their platform supports your use case.

These orchestrators create operational lock-in: You can’t effectively operate your AWS environment without the MSP’s tooling. You’ve traded AWS complexity for MSP dependency.

3. “Simplified” Interfaces That Hide AWS Reality

Abstraction layers that promise to “make AWS easy” can create a dangerous gap between what you think you’re deploying and what’s actually running in your account. When problems arise—and they always do—you discover that your team doesn’t understand the actual AWS infrastructure because they’ve only interacted with it through the MSP’s simplified interface.

The Real-World Impact of Lock-in

Scenario 1: The Price Increase

Your MSP announces a 30% price increase. With an LZA you own and open standards, you have options: negotiate from a position of strength, bring management in-house, or transition to another MSP in months. With a proprietary platform, you’re looking at risky and arduous re-platforming work—and your MSP knows it.

Scenario 2: The Service Quality Decline

Your MSP gets acquired. The new parent company shifts focus, key engineers leave, and service quality drops. With an open approach, you can transition smoothly. With lock-in, you’re stuck enduring declining service while planning an expensive migration.

Scenario 3: The Strategic Pivot

Your company wants to build internal cloud expertise and eventually self-manage. With LZA, your team can learn standard AWS tools and practices from day one. When you’re ready to transition, you already have the skills and the code. With proprietary platforms, your team has learned the MSP’s tools, not AWS—setting your in-house capability building back by years.

Scenario 4: The Platform Limitation

Your business needs evolve, and you need to implement a complex AWS architecture that isn’t supported by your MSP’s platform. You’re now in the worst position: paying for a platform that constrains you, unable to use native AWS capabilities, and facing the choice between living with limitations or undertaking an expensive re-platforming project.

How to Evaluate Your Current or Prospective MSP

Ask these critical questions:

1. “What landing zone solution do you use?”
   • Red flag: “Our proprietary solution” or vague answers. Subscription based landing zones (yes they exist!).
   • Green flag: “your own AWS Landing Zone Accelerator” or “a per-customer AWS Control Tower with Customizations for Control Tower”
2. “What happens to our infrastructure if we terminate the contract?”
   • Red flag: Vague answers about “transition planning” or “it depends”
   • Green flag: “You keep everything—we’ll help with knowledge transfer, and you’ll have all the code and documentation”
3. “Will our team learn AWS-native tools, or primarily your platform?”
   • Red flag: “Our platform abstracts AWS complexity away”
   • Green flag: “We teach AWS best practices and native tools”

The Cloudar Philosophy: Your Cloud, Your Terms

Here’s what that means in practice:

Full LZA Implementation

Every customer gets its own AWS Landing Zone Accelerator, deployed directly into their accounts with complete source code access to the LZA configuration. Deployments happen in your account, giving you end-to-end visibility on your Landing Zone.

AWS-Native Tooling

We use CloudFormation, CDK, AWS Config, Systems Manager—tools that work with or without us. If you hire another AWS expert or build an in-house team, they’ll recognize everything immediately.

Comprehensive Documentation

You can read about every configuration option today, in the documentation published by AWS. So while we pride ourselves in sharing our knowledge, you are not dependant on us to explain what is going on

Additionally, we write customer-specific documentation  in our Confluence – from architecture decisions to operational procedures.. If you decide to leave, we can provide you with an export of that information.

Open Book Operations

You have full Read Only access to your AWS environment —we’re partners, not gatekeepers. Want to check our work? Go ahead.

Standard AWS Best Practices

We follow AWS Well-Architected Framework principles and industry-standard patterns. No “special sauce” that only we understand.

We succeed by giving you excellent service so you want to stay, not by making it painful to leave.

The Economics of Freedom

Some argue that proprietary platforms are necessary to provide better service or lower costs. We disagree.

Lower costs come from:

• Automation that scales across customers (which we use)
• Deep AWS expertise (which we have)
• Efficient processes (which we’ve refined over years)

Not from locking customers into proprietary platforms.

Better service comes from:

• Highly skilled engineers (which we continuously train)
• Customer focus (which our retention rate proves)

Not from proprietary abstraction layers.

We’ve proven that you can deliver excellent MSP services at competitive prices while keeping customers completely free. In fact, we believe customer freedom makes us better—we can’t coast on lock-in, so we must continuously earn our customers’ business.

Making the Right Choice

Before signing with any MSP, ask yourself:

• Do I understand what I’m getting into? Can you clearly explain how your infrastructure will be deployed and managed?
• What’s my exit strategy if things don’t work out? Is it measured in weeks, months, or years?
• Am I choosing this approach for the right reasons? Is convenience masking a lack of control?
• Do I retain full ownership? Of code, configurations, documentation, and knowledge?

Red Flags in MSP Sales Processes

Be wary if you encounter:

• Heavy emphasis on “simplicity” with little discussion of the underlying AWS architecture
• Vague answers about exit strategies and transition processes
• Marketing focused on proprietary platforms as the primary differentiator
• Contracts that grant the MSP exclusive rights to infrastructure code
• Lack of clarity about what you actually own vs. what you’re licensing

Conclusion: Freedom as a Feature

In the rush to cloud transformation, it’s easy to prioritize speed and convenience. And yes, a well-designed proprietary platform can deploy faster than custom LZA implementation—at least initially.

But cloud strategy isn’t measured in weeks. It’s measured in years and decades. The question isn’t “who can get me to cloud fastest?” It’s “who can help me build sustainable cloud capabilities that serve my business long-term?”

The MSP industry has a pattern: some providers build their business model around customer stickiness achieved through proprietary tooling. They create beautiful interfaces and slick demos that abstract away AWS complexity. Then, months or years later, customers realize they’ve traded AWS vendor lock-in for MSP vendor lock-in—often worse, because at least AWS is standardized.

At Cloudar, we reject this model fundamentally. We believe that customer freedom isn’t a bug to work around—it’s a feature to build for. We’re proud to be an AWS Premier MSP Partner that wins business through excellence, not lock-in.

Your cloud infrastructure is too important to be held hostage by convenient abstractions. You deserve an MSP that treats you as a partner who will grow and evolve, not a captive customer who might someday try to escape.

Choose partners who believe you should always have the keys to your own kingdom. Choose partners who succeed by being valuable, not by being necessary.

Choose freedom.

The post The Hidden Cost of Convenience appeared first on Cloudar.

Cloudar Renews AWS MSP Partnership with a Perfect Score!

At Cloudar, we are very proud to announce that we have successfully renewed our AWS Managed Service Provider (MSP) partnership for the second time—and with a perfect score! This achievement further solidifies our position as a leading AWS MSP, ensuring that our clients receive the highest level of cloud expertise and managed services.

A Hard-Earned Accreditation

Achieving the AWS MSP competency is no easy feat. The renewal process involves an extensive and rigorous two-day external audit, where AWS evaluates a company’s capabilities in security, automation, DevOps, customer success and more. This intensive assessment ensures that only the best-in-class providers are recognized, and we are happy to have met and exceeded every requirement.

A Six-Year Legacy of Excellence

Cloudar has been an authorized AWS MSP for six years, continuously demonstrating our ability to deliver exceptional managed services to our clients. This designation reaffirms our deep expertise in AWS technologies, proactive monitoring, and automation, helping businesses optimize their cloud environments while focusing on their core operations.

The Only Belgium-Based AWS MSP

We take great pride in being the only AWS MSP headquartered in Belgium. In a competitive and ever-evolving cloud landscape, this distinction highlights our unwavering commitment to excellence and customer satisfaction. Our local team of AWS-certified experts works tirelessly to provide best-in-class cloud solutions tailored to each client’s needs.

An Exclusive Global Network

The AWS MSP designation is highly exclusive, with only 185 companies worldwide holding this prestigious competency. As part of this elite group, Cloudar continues to set the standard for managed cloud services, ensuring businesses maximize their AWS investments.

Why Work with an AWS MSP?

Partnering with an AWS MSP like Cloudar means businesses can focus on what truly matters: delivering value and innovation. Our expert team handles the complexity of cloud management, security, and optimization, allowing organizations to drive efficiency, reduce costs, and scale with confidence.

We are incredibly proud of this accomplishment and remain dedicated to helping businesses thrive in the cloud. Thank you to our customers, partners, and the entire Cloudar team for making this achievement possible!

Looking for a trusted AWS MSP partner? Get in touch with us today and discover how Cloudar can elevate your cloud journey!

The post Cloudar renews AWS MSP partnership appeared first on Cloudar.

AWS has limited responsibility

Yes, AWS takes away a lot of the so-called heavy lifting. They do this by managing all the physical infrastructure and providing Infrastructure as a Service (IaaS). They also go further up the stack and provide you with a managed Microsoft SQL Server (RDS) for example, or a managed NFS (EFS) in what we call Platform as a Service (PaaS). They even offer Software as a Service (SaaS) tools like QuickSight, which is a competitor to the likes of Tableau and Power BI. But there are very clear boundaries between what they do and don’t manage for you.

As you can see in this image of the AWS Shared Responsibility Model, everything in blue is the sole responsibility of the customer. That would be you! And what a huge responsibility it is: I’m sure you’ve heard the horror stories of companies misconfiguring AWS services and leaking confidential data or getting hacked. Or running up their cloud bill to insane amounts in days. Unfortunately those stories are true.

When pitching our Managed Services Offering to prospects, we sometimes get the question why they would need an MSP. Isn’t AWS managing everything already? In this article I’d like to debunk the biggest Cloud Myth: no, AWS does not manage everything, and yes, an MSP will add considerable value to your business. Not in the least because it allows you to focus more on that business, and less on the operational burden of your cloud environments.

You need trained brains

You can see why you would need the proper expertise to adequately manage your AWS environments. Sure, your developers can write your CloudFormation or Terraform code and make sure everything works. But your AWS doesn’t just need to be developed: it needs to be managed. At this point you have two options: either hire and train the staff you need to support and manage your AWS environments, or make use of an MSP.

We find that customers often have a very hard time finding skilled engineers, as there is a high demand for AWS profiles on the market. Keeping them on board once they’re trained is another challenge (recruiters are vicious!). To fully manage an AWS environment around the clock while providing good working conditions for your employees and accounting for the occasional absence, you’ll probably need a team of at least four engineers. Even if you don’t really have enough work for them to do.

The big advantage an MSP has is scale. Instead of all our customers implementing their own services 24/7, we provide them. And instead of hiring, constantly training and retaining qualified engineers, we’ve already got them on board. The service an MSP provides is in most cases cheaper than staffing your own operations, and you no longer have to worry about finding and keeping the talent you need.

Your MSP has got you covered

There are other benefits too: MSPs implement and operate your AWS presence in a Well-Architected way, and offer traditional services like monitoring, a service desk, backups and patching. They also make sure you don’t spend too much and advise you on architectural decisions. Not only will they help define a deployment strategy, they will be your developers’ best friends in a true DevOps kind of way. And last but not least, they’ll keep your environment secure, preferably by using a Cloud Security Posture Management System.

MSPs are trusted partners. We can be yours! To find out more, feel free to get in touch with us.

The post Why you should partner with a Managed Services Provider appeared first on Cloudar.

From fuel gauge to disk space alert

Let’s use this trip down memory lane as a stepping stone. Imagine your car is a simple EC2 instance. How would you feel if you had to log onto your server and open up Explorer or run a df just to find out how much disk space you had left on your system drive? What would you think of having to check your dashboards every day? Would you be content with a virtual dipstick, as it were? 

Thankfully, this is not our reality today. Even traditional monitoring systems have long been capable of providing threshold-based alerts. Think of them as configurable low fuel indicator alerts for your systems.

Threshold-based alerts: a solid start

The question we need to ask ourselves is whether we are content with threshold-based alerts. A single gigabyte of free disk space might be plenty on one server and impending doom on the next. How do we fix this? Percentage-based thresholds are an interesting option, but they also come with a few caveats. While 5% might be ample free space for a 20TB file server, it would be problematic for a build server.

So you need to differentiate. And guess. Can you predict your system needs based on historical events and best practices?

Now, if there is one thing computers are better at than humans, it’s spotting patterns. They can learn from those patterns and deduce when things are “not normal”. Then, they will kindly alert you when there is cause for alarm. Much like the “miles to empty” feature in your car.

Putting machine learning to good use

And that is exactly what AWS DevOps Guru will do for you. The service uses machine learning techniques to spot anomalies in your environment and alert you before accidents happen. DevOps Guru uses machine learning models that were nurtured by years of Amazon.com and AWS operational excellence. You can use these models to identify anomalous application behavior (e.g. increased latency, error rates, resource constraints, etc.) and surface critical issues that could cause potential outages or service disruptions.

As an official AWS Managed Service Provider, Cloudar is constantly looking for ways to improve customer service. We help our customers to reach the highest levels of uptime. Or more specifically: the lowest levels of unplanned downtime, which is different, but I digress.

And while we still use traditional threshold-based monitoring tools (which do a great job in their own respect), using ML-based predictive monitoring and anomaly detection is something we have been doing for a while. With, I must admit, mixed feelings…

The predictive monitoring trap

Let’s circle back to our story about fuel. Imagine your car yelling at you to stop for gas every few hundred miles, only for you to arrive at the gas station and learn that the tank is half full. That is exactly the issue with a lot of tools that provide anomaly detection: false positives. 

At first glance, false positives don’t seem too bad. But trust me, they are. I would even argue that they can be as bad as missing a true alert. Any on-call engineer will tell you what happens when you receive too many false positives: you stop paying attention.

So yes, there is a lot of complexity in building an ML-based monitoring tool. And our experience as a launch partner (bragging rights here) is that DevOps Guru does a good job when it comes to limiting false positives. But of course, we are looking forward to seeing the tool grow even more.

Did my blog post spark your interest? Cloudar is hosting an EMEA DevOps Immersion Day on June 22 with a strong focus on DevOps Guru. The Immersion Days in the US were a big success and we are organizing this EMEA session with AWS to accommodate EMEA timezones. Sign up here.

The post How machine learning can drastically limit your downtime appeared first on Cloudar.

Cloudar is part of a select club of AWS partners globally, that is allowed to perform Well Architected Reviews. You can find more details on that here. After a free audit, we can perform a remediation of all findings for you, which will bring you one step closer to being Well Architected. But that is just a moment in time in an ever-changing cloud landscape. It’s like buying a new laptop. The moment you buy it, it’s almost outdated. I’d like to see being Well Architected more as a continuous process, and not as a onetime goal. So your AWS practice never gets outdated.

Of course, as a company, you can make sure you not only get Well Architected, but also stay Well Architected. It will take a considerable amount of effort though, keeping up to date with all changes on AWS is no easy feat. Our sole focus is AWS, and even for us it’s hard to keep up. Even AWS engineers have a hard time staying up to date. So, when running stuff on AWS is not your core business, you’ll need a friend.

That friend should be your MSP. He will be the one helping you to comply with the 5 pillars of a Well Architected environment.

Operational Excellence
Your MSP partner should have plenty experience in managing cloud environments. To make sure you pick a partner that can be trusted, you can select one that has been audited by AWS here. They can offer you services like 24*7 monitoring and alerting, backups, patching, CI/CD setups. And they will be the ones responsible for the operational wellbeing of your setup.

Reliability
An experienced AWS MSP can design your environments in ways that they are reliable and self-healing. By means of multi-AZ or multi-region deployments, your mission critical applications can get high levels of uptime. You can even agree on (application based) availability SLA’s with your MSP.

Security
At AWS, security is job zero. It should be the same at your MSP. Cloud environments are targeted by bad people because they know it is very straight forward to get started. All it takes is a credit card to get rolling. It’s remarkably easy to get something working when you put in some effort. However, the times we have analyzed environments where the principles of least privilege were not followed (give them admin, we’ll worry about that later) or where resources were living wide open to the internet while there was no reason… Be very careful with what you deploy in the cloud. And pick an MSP that makes use of all AWS features related to security like CloudTrail, Config, WAF,… and can also offer you third party solutions like Trend Micro Deep Security, Splunk and others.

Performance efficiency
There are a thousand ways to get a certain result in AWS. And I think if you really try hard, you’ll find a thousand more. But in the end, you want the biggest bang for your buck. An MSP has the knowledge on how to build environments with the most suitable resources. And he will follow up on all new AWS features and service updates to see if they can be applied to your environment to make it even more efficient. This is really key as you don’t want to be caught with an outdated laptop.

Cost Optimization
Slightly related to performance efficiency, but much more than that. Unused resources. Underutilized resources. Overprovisioned instances. The Science that is Reserved Instances. Suboptimal data flows that generate costs. You want these things to be monitored for you and handled. An MSP will do just that. And through Service Management you will get updated on all possible cost optimizations.

The focus of next generation MSP’s is not the same as the focus of a traditional MSP. If you are convinced of the value of the Well Architected Framework (you should be), working closely together with an MSP is a very good way to make sure your environments are Well Architected, and stay that way.

The post Use your MSP to get and stay Well Architected appeared first on Cloudar.

Kontich, Belgium, February 26th, 2019 – Cloudar, Belgian based AWS Premier Consulting Partner, today announced it has achieved the Amazon Web Services Next-Generation MSP Partner Status.
The AWS Managed Service Partner Program equips the next generation of MSPs with the tools they need to deliver continuous innovation to customers regarding security, SecOps, DevOps, proactive monitoring, and streamlined management of their customers’ environment. Check out this cool blogpost for more info about what AWS expects from Next-Generation Managed Service Providers: https://aws.amazon.com/blogs/apn/what-exactly-is-a-next-generation-aws-managed-service-provider-msp/

Passing the rigorous 14-part, third-party validation audit for the AWS Managed Service Partner program is just another testament to Cloudar’s expertise and commitment to their customers’ success.
Cloudar is the first AWS Premier Consulting Partner headquartered in the Benelux that has achieved this prestigious AWS MSP status.

Why Work with an AWS Managed Service Provider (MSP)?

Cloudar has been part of the APN network since 2014 and has had a 100% focus on AWS since day one. This focus on one specific cloud allows Cloudar to excel and to have the best possible relationship with AWS.
In close collaboration with AWS, Cloudar has already achieved several AWS Competencies (DevOps/Government). All Cloudar engineers hold one or more AWS Certifications, including several AWS Specialties (Security/Advanced Networking/Big Data). Late last year, Cloudar achieved the AWS Premier Consulting status as the first company headquartered in Belgium. In the same year Cloudar got ISO/IEC 27001 certified for information security which is the internationally recognized and respected standard that applies an exacting, risk-based approach to determine the security of data in an organization, assessing IT structure, processes and people.
Entering the AWS MSP Program and being rewarded as an official AWS Managed Service Provider is another great milestone for Cloudar which recognizes the company’s 24/7 AWS Managed Services strategy.

About Cloudar
Cloudar was founded by Senne Vaeyens and Bart Van Hecke in 2014 with a 100% focus on Amazon Web Services.
As DevOps, AWS and infrastructure experts, Cloudar offers rock solid, high available and scalable solutions for any type of business in the AWS Public Cloud.
Being part of Cronos Groep( https://cronos-groep.be/en), Cloudar can offer their customers complete solutions that go beyond AWS expertise. With over 5,000 IT consultants, a 2017 revenue of 560M € and an average yearly growth rate of 15%, Cronos Groep has become one of the most solvent and trusted technology partners in Belgium and Luxemburg.
Cloudar has delivered dozens of agile, right-sized projects and provides 24/7 Managed Services to customers across all industries, creating a well-architected core from which these organizations can operate and grow their journey in the AWS Public Cloud. For more information, please visit https://www.cloudar.eu

The post Press Release: Cloudar being recognized as an official AWS Next-Gen Managed Service Provider appeared first on Cloudar.

Most often traditional managed services providers offered managed servers. There were some differences in how high in the stack your provider would support you (OS only, some SQL and AD or even full application support), but other than that you were given a server with an OS and what we call the Big Three of Managed Services: monitoring, patching and backups. The provider would also manage the underlying network infrastructure and storage boxes. But that was that. Infrastructure engineers would build your environment, hand it over to you, and you could start deploying your applications.

That infrastructure could be three things. Either dedicated physical servers, a multi-tenant virtualization platform or something that was called private cloud. It wasn’t really cloud, as it didn’t scale. It was just your own virtualization platform. A point also made by Bart Van Hecke: here.

Fast forward some years, and with public cloud, a big shift has been made. Managed infrastructure is no longer the be all and end all of a managed services company. Not only is the whole hardware layer that an MSP used to manage now managed by AWS, but a plethora of new services has been released. The result is that an MSP is now driven higher up in the stack. There is less to manage on the hardware side of things, but much more on PaaS and FaaS level.

A customer now gets a bucket full of Lego, and can start building. You can build beautiful things with Lego. But without any guidelines or help, you can also create the next Frankenstein. So what we see now is that unlike the early days where an engineer would throw a server over the fence and let the developer or application manager do his or her thing, it’s a journey. A journey where an engineer and a developer build things together. You’ve probably heard of this pretty thing called DevOps. It’s much more than just a buzz word. It quickly became the only proper way to move forward and work with the new technologies that AWS kept throwing at us.

As a next generation MSP, Cloudar also has a very solid consultancy business. And that is a match made in heaven. Not only do we take the burden of managing your servers out of your hands, but our skilled engineers help you in deploying your applications in a Well Architected Way. And the virtual infrastructure that comes from that, and is kept in version controlled CloudFormation or Terraform, will also be managed by us. And that is more than just an EC2 instance. It could be a PaaS platform like Beanstalk, ECS or EKS or it could be a FaaS Serverless platform based on Step Functions, Lambda, DynamoDB and API Gateway. Because in the end, developers want to develop and build new things, but they don’t want to manage and nurture what they have built 24*7.

So what we have seen now over the years during many customer engagements, is that we not only manage environments for customers, but we also teach customers how to work better. How to build efficient development pipelines instead of using FTP scripts and a local git to deploy to a static server. How to work together as dev and ops. And in return customers make us better, as they keep coming up with new requirements and new challenges.

The post About MSP’s and Lego appeared first on Cloudar.

Today that clear boundary has disappeared. System engineers are shifting more and more to automation and thus very basic development, or scripting. But at the other side of the spectrum, application engineers and developers are shifting more and more to the infrastructure side. Why? Infrastructure as code. CloudFormation. Boto. Terraform. AWS CDK. In a true public cloud environment, where every single administrative action on infrastructure level is a simple API call, things are changing, and DevOps is born.

You rarely saw devs running around the office with a screwdriver and rack mounts. If they needed a server, they’d ask one to be procured. And waited a few weeks. Now application engineers can quite easily build their own infrastructure to run their applications. It’s just code, right? And they do. Oh boy they do…

However, in most cases it is undesirable to have an application engineer create infrastructure. There is the principle of segregation of duties. Furthermore, it’s very rare a skilled dev has a strong infrastructure background. So while he can probably spin up resources to support his application, the question is: is it Well Architected? And that is where a next gen MSP comes into play. Cloudar was selected by AWS to perform Well Architected Reviews. Our AWS Solution Architect Professional engineers that have followed the required extra training are allowed to perform rigid reviews of existing business critical workloads. Needless to say, each environment we build, needs to adhere to the same Well Architected Principles.

But what if a developer wants to go full serverless, and change infrastructure components rapidly? Things like Lambda’s. Can he wait for an engineer at the MSP to create those resources, throw them away, reconfigure them? Probably not. The cloud allows for speed, and you don’t want your MSP to be a potential bottleneck. Now what?

Here, the answer is again: infrastructure as code. If you demand all infrastructure to be written in code, you can allow your devs to play around in development to deploy extra infrastructure resources. And then when they are happy, and they went through dev and test, and are ready to commit to UAT, insert a code review approval step. Have the engineers that will be actually supporting the environment 24×7 review the infrastructure code. Is what will be deployed to UAT and later on to PRD still Well Architected? Does it adhere to your internal support standards? And for the mental health of the on call engineers: will it be stable and not generate alerts at 3 am in the morning?

So you see that devs will need to work with sysops, and vice versa. Certainly in a project phase. You want to work as agile as possible, but still have a reliable and secure environment. One of the strong points of Cloudar is that we have both. We have a very solid managed services business, but we also have a flourishing consultancy practice. Our people love working with your devs. We like them. Sometimes we even want to cuddle them. Everything it takes to have your workload running 24*7, but reduce your time to market by allowing devs to go crazy until stuff moves to production. Because production, is serious business.

The post A new reality: Devs creating infrastructure. And how to deal with that… appeared first on Cloudar.

The post Cloudar as a Next Generation MSP appeared first on Cloudar.