Operations | Monitoring | ITSM | DevOps | Cloud

We recently wrote about the reasons why serverless apps fail and explored some ideas to make architectures more resilient and scalable. Some of these architectural designs can become expensive if we don’t consider the financial impacts of architectural decisions. With proper care and consideration to this aspect, it is possible to achieve the same value in terms of scalability and resiliency while keeping costs at a manageable level.

The cloud is becoming the vehicle for next-generation digital business and has emerged as the go-to platform for start-ups looking to thrive in today's highly dynamic and competitive market. Traditional on-premises IT solutions require higher investments in hardware, software licenses, maintenance, and training costs, which makes them ill-suited for start-ups.

If you’ve been operating in the cloud for some time now, chances are your business has changed since you first made that move. Has your cloud usage grown considerably—and your OpEx costs? Is that just the cost of doing business in the cloud? It doesn’t have to be. Here’s how you can rationalize your infrastructure and determine if there are cloud expenses you can reclaim and even if it makes sense to move some of your cloud deployments into co-location.

In recent reports, it is stated that datacenter-based GPU deployments is the fastest sector, and again, that’s no surprise. The cloud has had its own incredible growth over the years, and it’s only natural that these two technologies are starting to work in harmony. As a matter of fact, most public clouds have GPU offerings, which leads us to the meat of this blog post: Oracle Cloud.

An AWS Auto Scaling group (ASG) is a fleet of EC2 instances that can scale up or down depending on application demand. The elasticity of Auto Scaling groups makes them highly-attractive options for enterprises who do not want to invest in purchasing expensive hardware only to respond to sudden or temporary spikes in application demand.

There is an interesting discussion going on around how Serverless is more of a spectrum rather than a binary choice. The move towards the Serverless-end of the cloud spectrum builds upon a decades-old trend, which is why Serverless is here to stay.

Looking for an end to end visibility on your Serverless Application made with Azure resources? This article is for you. Consider there is a transaction between the Azure Services. With the existing solutions offered by Azure, you cannot have the visibility on the transaction as well as the stages in the transactions. Here comes the Business Activity Monitoring in Serverless360. With a simple scenario, we will see how to use Business Activity monitoring and track business data.

Launching a production app onto the cloud is a big task with a ton of tiny sub-tasks, and it can all be pretty overwhelming. We're here for you. We've launched an app ourselves (Blue Matador, our cloud infrastructure monitoring software). In the coming weeks, we will walk you through everything you need to know and do to successfully launch your app—with the least amount of effort.

In January, AWS announced the ability to export RDS snapshots to S3. This new feature allows you to export your RDS data to S3 buckets in Apache Parquet format. Today, I’m happy to say that we’ve added a new action to help with this feature: Export RDS Snapshots. This new action will automate the process of exporting RDS snapshots to S3 on a daily basis.