How to Choose a Cloud Provider: Checklist

Every developer strives to speed up product development while maintaining enough flexibility and confident control over the process. Microservices application architecture helps solve these tasks and, over the past 10 years, has begun actively competing with the traditional monolithic approach. To begin, let’s look at the difference between them. Microservices Architecture vs. Monolith The difference between these two software development approaches is easiest to illustrate with an example. Let’s imagine two online stores: one implemented as a monolith and the other as microservices. A monolithic online store is a single, indivisible structure that combines all components: databases (catalog, customer data), shopping cart, order and payment forms. All of these elements are tightly interconnected and located on the same server. In a microservices system, each component is an independent module that developers can work on separately. And naturally, nothing requires hosting these modules on a single server. Thus, microservices architecture is a kind of constructor that allows you to add new elements painlessly as you scale the application. A monolith, on the other hand, can be compared to a solid wall: scaling here is only possible by adding another identical monolith. It’s worth adding that microservices are sometimes mistakenly perceived as a set of very small services. This is not the case: for example, the database of a large online store may contain millions of records and occupy tens of gigabytes, yet still be just one of the modules within the microservices architecture of the whole application. Comparing Microservices and Monoliths by Key Criteria Now let’s look at the main characteristics of microservices technology in comparison with a monolith and see how both approaches solve the same developer tasks. Release Cycles Development speed and frequency of updates increase with microservices thanks to modularity: changes are made not to the entire codebase but to individual modules. With a monolith, however, the whole platform must be updated first, which increases testing and debugging time. As a result, development slows down and updates are released less frequently. Technology Stack The microservices model offers significantly greater flexibility because each service can be written in its own programming language and may use different libraries and data-storage technologies. With a monolith, the situation is different: changing the technology stack is nearly impossible. Developers are forced to stick to the initial tools. Developer Onboarding Each module in a microservices architecture is self-contained, making it possible to bring in programmers who are familiar with the functionality of a specific service. This substantially lowers the onboarding threshold. With a monolith, new developers must dive into the code of the entire application, understand the functions of every block, and only then begin productive work. Thus, maintaining a monolith is more dependent on specific team members. Optimization Characteristics The modularity of microservices architecture also positively affects optimization, since developers can optimize each service separately. Optimizing a monolithic structure is more difficult because the team must account for links between indivisible blocks, and updating any one of them inevitably affects the entire application. Application Scalability The distributed structure of microservices and their ability to run on separate servers make scaling fast and easy. In monoliths, scaling one component inevitably requires scaling the entire application as a whole. Fault Tolerance Because services are hosted on different servers and have a modular structure, microservices architecture achieves independence of each module. This significantly increases system resilience: a failure in one service does not cause the entire application to fail. With a monolith, the situation is different: all components are tightly interconnected, so the failure of one module can make the entire application inoperable. Do I Need to Switch to Microservices Right Now? As we’ve seen, microservices have advantages in many key areas. But does this mean you need to abandon monoliths as an outdated approach and immediately switch to microservices? The answer depends on the current state of your project. And let’s say right away: rushing to adopt microservices is not always the right choice. Distributed architecture also has its drawbacks. First, microservices require ensuring network connectivity between modules. If a network connection is unstable, this leads to delays and data inconsistencies, which create potential problems in application behavior. Second, each module of a microservices system requires separate testing and health monitoring. Additionally, you will need to allocate cloud resources for each module, which may increase costs. Third, with the microservices approach, teams responsible for different modules may encounter interaction issues. This means you may need a connecting link in the form of DevOps specialists who can streamline collaboration and speed up development. All the factors listed above allow us to conclude that the transition to microservices must be timely. Usually, during the early stages of a project, this is unnecessary, especially if developers have limited human or financial resources. Switching to a microservices architecture makes sense when there is a clear need for significant scaling, and scaling a monolith has already become difficult. Microservices may be right for you if: You have a large team. In this case, it makes sense to divide the team into separate, independent groups, each responsible for its own service; You have a complex, branched application. In this case, it’s far more convenient to update and maintain modules separately than to rebalance the entire system each time; Your application traffic is highly variable. For example, you see sharp spikes in load during certain periods. Microservices' distributed structure allows quick scaling during peak loads, after which you can easily return to normal capacity levels; Your application is frequently updated. Working with separate modules in this scenario is much simpler, and new releases will be significantly faster. If your project meets at least one of these criteria, this is a reason to consider breaking it into independent elements. However, if your application is relatively small and does not require frequent updates, it is reasonable not to rush away from monolithic architecture. Useful Tools for Organizing Microservices A modern development approach requires a containerization platform. In most cases, developers use Docker for these purposes. Docker tools allow them to isolate the application from the infrastructure, meaning they can work with it equally well locally or in the cloud, which is very convenient for development. Once containers become numerous, an orchestrator becomes essential for managing and organizing groups of containers. Kubernetes is most commonly used as an orchestrator due to its strong compatibility with Docker. Another necessary tool is a load balancer, which ensures even distribution of network traffic across all cloud resources. This significantly increases the application’s fault tolerance.

Serverless is one of the popular directions in IT and continues to grow. Cloud providers are ready to provide all the necessary infrastructure and maintain it, and the user pays only for the execution time of a function—idle time is not billed. Serverless Ecosystem Serverless architecture is a way of building applications in which the developer writes the application logic, while the cloud provider is responsible for launching that logic, monitoring, scaling, maintaining the execution environment, and managing load planning. This is not always an external provider; such infrastructure can also be implemented inside a company using its own computing resources. The simplification of working with infrastructure traces back to the appearance of the first IaaS (Infrastructure as a Service), where the provider simply offered virtual infrastructure for rent, and then extended to widespread BaaS (Backend as a Service), where a developer’s microservice or a database is simply several containers running in the provider’s environment, and in the case of a database, with preconfigured replication. Another product is FaaS (Function as a Service), where the execution unit is a single function. In part, this resembles a microservices approach. Your function should not rely on state between calls (it must be stateless), because each call is launched by the provider as a separate instance in a container. There are also some limitations imposed by the cloud platform: not all programming languages can be used to write function code (although the list is usually wide), and there are limits on execution time and memory usage. The exact limits differ by platform and may depend on your pricing plan. Many providers offer trial periods from three months to a year with limits on the number of requests. The foundation of Serverless is FaaS and the provider’s ecosystem of products. Typically, there are Databases, Authorization Services, API Gateways, Message Brokers (such as Kafka), all provided as services (BaaS) that your function can integrate with. Architecture Each provider may offer a unique set of services, but applications built on FaaS generally have similar architectures. As an example of integration between provider products, you can consider a TODO application (the example is taken from the AWS website). The application logic is packaged in lambda functions, which interact with the DynamoDB database, provided by AWS as a separate service. In front of the functions is the API Gateway, which handles incoming requests and routes them appropriately. The architecture also includes the Amplify Console for managing the web interface of the application and the Amazon Cognito authentication service. Advantages and Disadvantages The main positive aspects of Serverless typically include: Flexible scalability Helps handle peak loads and rapid product growth. The provider will automatically scale the function, and when demand decreases, resource consumption will shrink. Pricing You pay only for the execution time of the function. For example, on AWS, the price includes the cost of function invocations and the amount of memory (GB/s) allocated during execution. Even with 24/7 availability (with some nuances), you do not pay for periods of inactivity. Automation CI/CD, integration with other services, monitoring, log management, and maintaining the execution environment—the provider handles all of this, allowing for faster product deployment. Compared to BaaS infrastructure or full server control (VPS), deploying an application into cloud functions has its downsides: Resource limits Cloud functions have memory and execution time limits, as well as restrictions on data sizes sent or received. Here are examples of such limits in AWS. Cold starts The provider will not keep a container with your function running at all times. If the function has been idle for some time, its next invocation will require time to start up. Startup time depends on the programming language, code size, and the provider’s internal processes, and can reach up to 10 seconds. Here’s a small article with examples on the topic, and a GitHub repo with code and research results. Best Practices Although FaaS-based systems and service ecosystems resemble microservice architecture and functional programming, they have their own best practices beyond monitoring, logging, request tracing, and mocking service responses. Warm Start If your application requires consistently fast responses, cold starts can be a major issue. The solution is to constantly “warm up” the function, for example, by periodically sending requests that create some load so the provider keeps the function active. The load itself does not matter; what matters is triggering the function. If necessary, the provider will scale by starting additional instances on the fly. Some providers offer built-in mechanisms for this (e.g., AWS), allowing you to keep a certain number of instances always running. Fan-Out Pattern A pattern that allows you to bypass memory, data size, and execution time limits by splitting a large task into smaller chunks. Downloading and processing data in chunks, sending emails in small batches—cloud functions will execute tasks in parallel across different function instances. The trade-off is more complex application code and paying for more function invocations. Event Driven Pattern Cloud FaaS functions can be triggered not only via API Gateway or direct invocation. A trigger can be an event from any integrated service, such as a message from Kafka. Event-driven code organization works extremely well for FaaS. Cost Optimization Unlike a fixed-price service (e.g., renting a VPS for a year), Serverless costs are composed of several different services, each with its own billing model. Continuous monitoring of costs and resource utilization, along with load planning, is key to reducing infrastructure expenses. Some providers have special offerings, such as AWS Lambda Reserved Concurrency, which allows reserving Lambda instances and keeping them active on a cheaper pricing tier. Tools for Working with Serverless Serverless Framework An open-source tool for simplifying the development, deployment, and management of serverless applications. It allows developers to focus on writing code without worrying about infrastructure and provider configuration. It supports AWS, Azure, Google Cloud, IBM Cloud, Oracle Cloud. It enables local function testing, integrates with CI/CD systems like Jenkins or Travis, has a large plugin ecosystem, and allows developers to create their own plugins. Terraform A HashiCorp tool representing the "infrastructure as code" approach. It allows defining infrastructure using configuration files in HCL (HashiCorp Configuration Language), which describe the desired infrastructure state rather than the steps to achieve it. Like Serverless Framework, Terraform supports many major cloud providers and allows defining modules, i.e., reusable sets of configuration files for creating and managing infrastructure components. AWS SAM The Serverless Application Model is an open framework created by AWS for developing, testing, and deploying serverless applications on AWS. SAM provides a simplified way to build serverless apps based on CloudFormation, AWS’s main tool for infrastructure as code. Kubeless Unlike the previous tools that focus on cloud providers, Kubeless is a serverless framework for Kubernetes. It allows creating and managing serverless functions directly inside your Kubernetes cluster. It works with standard Kubernetes objects like Deployments, Services, Ingress, etc. It provides scaling and fault tolerance for functions, has a CLI, and integrates with the Kubernetes ecosystem. OpenFaaS An open-source serverless framework. It allows creating functions in many programming languages, including Python, Node.js, Go, Ruby, Java, and others. It supports scaling and ensures fault tolerance. OpenFaaS integrates with Kubernetes and Docker Swarm. Areas of Application Today, Serverless applications cover a wide range of tasks, from notification and mailing services to analytics platforms, data stream processing, webhooks, game servers, file and multimedia processing, IoT applications, adapters for external services, monitoring and logging systems, business process automation, content rendering servers, customer support chatbots, and testing or deployment servers. Many examples exist within the Serverless Framework ecosystem. Major IT companies are migrating some processes to Serverless. For example: Netflix uses FaaS for encoding and transcoding video when preparing video streams for different devices. Airbnb uses Serverless in its StreamAlert system for real-time data analysis. Using Serverless is not only a way to reduce infrastructure costs, but also a tool for increasing development efficiency and flexibility. Serverless allows for rapid development and deployment of new functions and applications, as well as scaling them based on business needs. Additionally, Serverless technologies support creating more reliable and fault-tolerant applications because cloud providers ensure high availability and automatic scaling. This helps companies avoid downtime or service failures that could harm their reputation and customer experience. Development of Serverless Serverless architecture represents a significant step in the evolution of cloud computing, allowing companies to focus on application development without worrying about managing infrastructure. This approach brings flexibility, scalability, and efficiency to development processes while reducing maintenance and operational costs. In the future, we can expect development in several areas: Greater integration and compatibility between cloud providers, allowing users to choose the best solution without vendor lock-in. New services and tools tailored for Serverless architectures, such as advanced tools for monitoring, performance optimization, security, and expanded development and deployment capabilities. Growing adoption among companies, increasing the market’s growth and expanding opportunities for innovations and new business models. Serverless technologies are poised to continue reshaping the landscape of cloud computing, enabling companies to focus on building applications rather than managing infrastructure. With more integrations, new tools, and broader adoption, Serverless will increasingly become a key element in the modern developer’s toolkit.

When setting up a virtual server, an important decision is choosing the best server OS for your tasks. The operating system will largely determine the server's overall functionality and affect its performance and security. In this article, we'll examine several available options and discuss the advantages and disadvantages of each so you can make an informed choice. How Operating System Choice Affects Your Server Let's define the list of factors that the hosting operating system influences: Performance An operating system is software that manages hardware and provides an interface for interacting with it. Like any software, the operating system consumes part of the computing resources. For example, Windows Server will consume more than Ubuntu Server due to factors like the graphical interface. Before installing a particular operating system, determine whether you need the services and functionality it provides. A graphical interface won't affect web server functionality at all. Are you willing to spend additional resources on more comfortable administration? Compatibility In general, most software will be available to both Linux and Windows users. Developers are interested in having versions for different operating systems. Even some Microsoft applications, which theoretically should be interested in promoting their operating systems, run on Linux—for example, MS SQL databases. But, of course, not all Microsoft software can be run on Linux. For Windows, there's a special software layer that allows running Linux applications—WSL. If a Windows port of the application doesn't exist, WSL will help run it. Both Windows and Linux allow users to perform most work tasks. Compatibility affects administration convenience and performance. For example, PHP is available on both operating systems, but on Linux it runs faster. And running some applications will require additional effort. Cases where technology is only available on one operating system are rather exceptions. For example, if a company needs a terminal server or Active Directory, they'll have to use Windows Server. Licensing Almost all Linux distributions are distributed free of charge, while you'll have to pay for Windows Server and additional components. Security What's more secure: Windows or Linux? This is quite a debatable question. In general, each operating system has a sufficient number of information security tools available. System security primarily depends on the user. You can catch a virus on both Windows and Linux. But the probability of catching a virus on Windows is higher, simply because most viruses target Windows systems. Windows Server Virtual Servers Windows is one of the most popular operating systems. In 2008, Microsoft released a special version for virtual servers—Windows Server. Windows Server offers high performance, a rich set of features, and broad compatibility with other software and services. However, it can be more expensive in terms of licensing. Windows Server has many different versions, each with its own features and areas of application. Depending on the Windows Server version, additional functionality may be available to the user. For example, cloud infrastructure support, improved resource management and security, and tools for easier server management and monitoring. Depending on the specific business needs and constraints, one of the Windows Server versions may be better suited for use on a virtual server. Advantages of Windows Server Ease of use. Windows Server has a familiar and understandable interface that's easy to learn. Compatibility. Windows operating systems are very widespread, and many applications have versions specifically for them. For working with applications that don't have a special Windows version, WSL exists. Support. Windows Server has extended support from Microsoft, which means the server will receive updates for a long time. Integration with other Microsoft products. Windows Server easily integrates with other Microsoft products, such as Active Directory, Exchange, and SharePoint. Disadvantages of Windows Server Complexity of hosting websites. When working on Windows, as with any other operating system, you can host websites, but it will be more complex. Licensing cost. Many solutions that are free to use on Linux require paid licenses on Windows Server. Security vulnerabilities. Many viruses target Windows operating systems specifically, which increases the risk of server infection. Hardware requirements. Windows Server is quite demanding on hardware, and versions newer than Windows Server 2008 don't support 32-bit architecture. Virtual servers are mainly used by companies and enterprises, not private individuals. For them, the question of benefit stands above the convenience of a familiar interface. Therefore, using Windows Server as a server operating system is usually the exception rather than the rule. For example, Windows Server is used to implement remote desktops and terminal servers. Linux Virtual Servers The Linux kernel is the heart of the Linux family operating system. It's a set of software that provides basic functions: memory management, filesystem operations, and communication with hardware. The Linux kernel provides the connection between software and computer hardware, allowing programs to interact with computer resources. It also provides mechanisms for multitasking, allowing multiple programs to run simultaneously and ensuring their security. Linux operating systems are various Linux distributions that have their own features and toolsets. Each distribution is suitable as an operating system for a server, but they are usually used for different purposes: Ubuntu is used as a desktop OS, Debian as a base for other distributions, Kali Linux for network security, and distributions like Rocky Linux or AlmaLinux for server tasks. Next, we'll look at some of these systems and talk about what tasks they should be used for as operating systems for VPS/VDS. Advantages of Linux systems: Reliability Free software Configuration flexibility Compatibility with many hardware platforms Low resource requirements Large selection of shells Disadvantages: Administration complexity Limited application support Unfamiliar interface Absence of some popular applications Debian Debian is an operating system based on the Linux kernel and freely distributed under the GNU GPL license. Debian is one of the most stable and reliable Linux distributions and supports a large number of processor architectures, including x86, x86-64, ARM, MIPS, and PowerPC. Debian has a package manager mechanism that allows easy installation and updating of software, as well as creating backups and restoring the system. Debian also has a configuration management system that allows easy system setup and administration. For server tasks, Debian provides stability and long-term support, which are necessary for reliable long-term server operation. It also has many tools for server monitoring and management, as well as an extensive support community for problem-solving. Ubuntu Ubuntu Server is one of the Debian-based distributions used in server environments. It's the familiar Ubuntu OS to many, but without a graphical interface. Interaction is carried out through the terminal. Ubuntu Server offers a high degree of stability and reliability, as well as extended system management and configuration capabilities. It also has an apt package manager, which makes it easy to install and update software. Ubuntu Server is used for deploying web servers, databases, network equipment, cloud services, and much more. It also supports virtualization and is used as a guest OS in virtualization environments such as VMware and VirtualBox. Kali Linux Kali Linux is a Linux distribution specializing in information security and penetration testing tools. It's based on Debian and has over 600 tools for conducting security tests. If you plan to work in information security, then Kali Linux is ideal for this task. In addition, Kali Linux is also used for information security training and practicing skills in this area. However, it should be kept in mind that some tools in Kali Linux may be illegal or unethical in some countries and jurisdictions, and their use may violate laws and regulations. Therefore, before using Kali Linux, you need to ensure that you're acting in accordance with applicable law. Rocky Linux and AlmaLinux Note: CentOS, which was previously popular for server tasks, ended its traditional support model in 2021. CentOS Stream became a rolling-release distribution that serves as an upstream development platform for Red Hat Enterprise Linux (RHEL), making it less suitable for production servers that require stability. As a result, the community created two enterprise-grade alternatives that continue the legacy of CentOS: Rocky Linux and AlmaLinux. Rocky Linux and AlmaLinux are free, open-source distributions created as direct replacements for CentOS. Both are built from RHEL sources and offer long-term support and stability, maintaining binary compatibility with RHEL. One of the main advantages of these distributions is that they provide proven and reliable software and security and stability updates. They also have the dnf package manager (evolution of yum), which allows easy installation and updating of software. As server operating systems, Rocky Linux and AlmaLinux are used for deploying web servers, databases, network equipment, and various services. They're also suitable for use in virtualized environments such as VMware and VirtualBox. Which Linux System to Choose If you don't plan to use your server for high-load tasks, then Ubuntu or another desktop Debian distribution with a friendly interface will suit you, in which you'll be comfortable working. If we're talking about using a server in commerce with high load, then choose Rocky Linux or AlmaLinux. These operating systems are oriented toward use in such conditions. If you want to work in information security, then choose Kali Linux. Conclusion In this article, we examined the main operating system options for a virtual server. Each has its own advantages, disadvantages, and areas of application. Still, it's important to remember that the listed operating systems, in most cases, provide a decent level of performance and operability.