DevOps

DevOps with .NET MAUI using GitHub Actions & Azure DevOps

Let's learn how to get started with a starter DevOps pipeline with .NET MAUI using GitHub Actions & Azure DevOps

We'll walkthrough some sample pipelines and learn how to configure the settings. You'll learn tips and tricks to help you add DevOps goodness to all your .NET MAUI apps!

#devops #github #dotnet #azure 

A tool To Bring Existing Azure Resources Under Terraform's Management

Azure Terrafy

A tool to bring your existing Azure resources under the management of Terraform.

Goal

Azure Terrafy imports the resources that are supported by the Terraform AzureRM provider within a resource group, into the Terraform state, and generates the corresponding Terraform configuration. Both the Terraform state and configuration are expected to be consistent with the resources' remote state, i.e., terraform plan shows no diff. The user then is able to use Terraform to manage these resources.

Non Goal

The Terraform configurations generated by aztfy is not meant to be comprehensive. This means it doesn't guarantee the infrastruction can be reproduced via the generated configurations. For details, please refer to the limitation.

Install

From Release

Precompiled binaries are available at Releases.

From Homebrew

brew update && brew install aztfy

From Go toolchain

go install github.com/Azure/aztfy@latest

Precondition

There is no special precondtion needed for running aztfy, except that you have access to Azure.

Although aztfy depends on terraform, it is not required to have terraform pre-installed and configured in the PATH before running aztfy. aztfy will ensure a terraform in the following order:

• If there is already a terraform discovered in the PATH whose version >= v0.12, then use it
• Otherwise, if there is already a terraform installed at the aztfy cache directory, then use it
• Otherwise, install the latest terraform from Hashicorp's release to the aztfy cache directory

(The aztfy cache directory is at: "<UserCacheDir>/aztfy")

Usage

Follow the authentication guide from the Terraform AzureRM provider to authenticate to Azure.

Then you can go ahead and run aztfy resource [option] <resource id> or aztfy resource-group [option] <resource group name> to import either a single resource, or a resource group and its including resources.

Terrafy a Single Resource

aztfy resource [option] <resource id> terrafies a single resource by its Azure control plane ID.

E.g.

aztfy resource /subscriptions/0000/resourceGroups/rg1/providers/Microsoft.Compute/virtualMachines/vm1

The command will automatically identify the Terraform resource type (e.g. correctly identifies above resource as azurerm_linux_virtual_machine), and import it into state file and generate the Terraform configuration.

❗For data plane only resources (e.g. azurerm_key_vault_certificate), the resource id is using a pesudo format, as is defined here.

Terrafy a Resource Group

aztfy resource-group [option] <resource group name> terrafies a resource group and its including resources by its name. Depending on whether --batch is used, it can work in either interactive mode or batch mode.

Interactive Mode

In interactive mode, aztfy list all the resources resides in the specified resource group. For each resource, user is expected to input the Terraform resource address in form of <resource type>.<resource name> (e.g. azurerm_linux_virtual_machine.test). Users can press r to see the possible resource type(s) for the selected import item. In case there is exactly one resource type match for the import item, that resource type will be automatically filled in the text input for the users, with a 💡 line prefix as an indication.

In some cases, there are Azure resources that have no corresponding Terraform resources (e.g. due to lacks of Terraform support), or some resources might be created as a side effect of provisioning another resource (e.g. the OS Disk resource is created automatically when provisioning a VM). In these cases, you can skip these resources without typing anything.

💡 Option --resource-mapping/-m can be used to specify a resource mapping file, either constructed manually or from other runs of aztfy (generated in the output directory with name: .aztfyResourceMapping.json).

After going through all the resources to be imported, users press w to instruct aztfy to proceed importing resources into Terraform state and generating the Terraform configuration.

As the last step, aztfy will leverage the ARM template to inject dependencies between each resource. This makes the generated Terraform template to be useful.

Batch Mode

In batch mode, instead of interactively specifying the mapping from Azurem resource id to the Terraform resource address, users are expected to provide that mapping via the resource mapping file, with the following format:

{
    "<azure resource id1>": "<terraform resource type1>.<terraform resource name>",
    "<azure resource id2>": "<terraform resource type2>.<terraform resource name>",
    ...
}

Example:

{
  "/subscriptions/0-0-0-0/resourceGroups/tfy-vm/providers/Microsoft.Network/virtualNetworks/example-network": "azurerm_virtual_network.res-0",
  "/subscriptions/0-0-0-0/resourceGroups/tfy-vm/providers/Microsoft.Compute/virtualMachines/example-machine": "azurerm_linux_virtual_machine.res-1",
  "/subscriptions/0-0-0-0/resourceGroups/tfy-vm/providers/Microsoft.Network/networkInterfaces/example-nic": "azurerm_network_interface.res-2",
  "/subscriptions/0-0-0-0/resourceGroups/tfy-vm/providers/Microsoft.Network/networkInterfaces/example-nic1": "azurerm_network_interface.res-3",
  "/subscriptions/0-0-0-0/resourceGroups/tfy-vm/providers/Microsoft.Network/virtualNetworks/example-network/subnets/internal": "azurerm_subnet.res-4"
}

Then the tool will import each specified resource in the mapping file (if exists) and skip the others.

Especially if the no resource mapping file is specified, aztfy will only import the "recognized" resources for you, based on its limited knowledge on the ARM and Terraform resource mappings.

In the batch import mode, users can further specify the --continue/-k option to make the tool continue even on hitting import error(s) on any resource.

Remote Backend

By default aztfy uses local backend to store the state file. While it is also possible to use remote backend, via the --backend-type and --backend-config options.

E.g. to use the azurerm backend, users can invoke aztfy like following:

aztfy --backend-type=azurerm --backend-config=resource_group_name=<resource group name> --backend-config=storage_account_name=<account name> --backend-config=container_name=<container name> --backend-config=key=terraform.tfstate <importing resource group name>

Import Into Existing Local State

For local backend, aztfy will by default ensure the output directory is empty at the very begining. This is to avoid any conflicts happen for existing user files, including the terraform configuration, provider configuration, the state file, etc. As a result, aztfy generates a pretty new workspace for users.

One limitation of doing so is users can't import resources to existing state file via aztfy. To support this scenario, you can use the --append option. This option will make aztfy skip the empty guarantee for the output directory. If the output directory is empty, then it has no effect. Otherwise, it will ensure the provider setting (create a file for it if not exists). Then it proceeds the following steps.

This means if the output directory has an active Terraform workspace, i.e. there exists a state file, any resource imported by the aztfy will be imported into that state file. Especially, the file generated by aztfy in this case will be named differently than normal, where each file will has .aztfy suffix before the extension (e.g. main.aztfy.tf), to avoid potential file name conflicts. If you run aztfy --append multiple times, the generated config in main.aztfy.tf will be appended in each run.

How it Works

aztfy leverage aztft to identify the Terraform resource type on its Azure resource ID. Then it runs terraform import under the hood to import each resource. Afterwards, it runs tfadd to generate the Terraform template for each imported resource.

Demo

Limitation

There are several limitations causing aztfy can hardly generate reproducible Terraform configurations.

N:M Model Mappings

Azure resources are modeled differently in AzureRM provider.

For example, the azurerm_lb_backend_address_pool_address is actually a property of azurerm_lb_backend_address_pool in Azure platform. Whilst in the AzureRM provider, it has its own resource and a synthetic resource ID as /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/group1/providers/Microsoft.Network/loadBalancers/loadBalancer1/backendAddressPools/backendAddressPool1/addresses/address1.

Another popular case is that in the AzureRM provider, there are a bunch of "association" resources, e.g. the azurerm_network_interface_security_group_association. These "association" resources represent the association relationship between two Terraform resources (in this case they are azurerm_network_interface and azurerm_network_security_group). They also have some synthetic resource ID, e.g. /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/mygroup1/providers/microsoft.network/networkInterfaces/example|/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/group1/providers/Microsoft.Network/networkSecurityGroups/group1.

Currently, this tool only works on the assumption that there is 1:1 mapping between Azure resources and the Terraform resources. For those property-like Terraform resources, aztfy will just ignore them.

AzureRM Provider Validation

When generating the Terraform configuration, not all properties of the resource are exported for different reasons.

One reason is because there are flexible cross-property constraints defined in the AzureRM Terraform provider. E.g. property_a conflits with property_b. This might due to the nature of the API, or might be due to some deprecation process of the provider (e.g. property_a is deprecated in favor of property_b, but kept for backwards compatibility). These constraints require some properties must be absent in the Terraform configuration, otherwise, the configuration is not a valid and will fail during terraform validate.

Another reason is that an Azure resource can be a property of its parent resource (e.g. azurerm_subnet can be its own resource, or be a property of azurerm_virtual_network). Per Terraform's best practice, users should only use one of the forms, not both. aztfy chooses to always generate all the resources, but omit the property in the parent resource that represents the child resource.

Additional Resources

• The aztfy Github Page: Everything about aztfy, including comparisons with other existing import solutions.
• Kyle Ruddy's Blog about aztfy: A live use of aztfy, explaining the pros and cons.
• aztft: A Go program and library for identifying the correct Terraform AzureRM provider resource type on the Azure resource id.
• tfadd: A Go program and library for generating Terraform configuration from Terraform state.

Download Details:

Author: Azure
Source Code: https://github.com/Azure/aztfy 
License: MPL-2.0 license

#go #golang #devops #tool 

Learn Docker for Beginners - FULL COURSE in 90 Minutes

Docker Tutorial for Beginners | FULL COURSE in 90 Minutes

Docker Tutorial for Beginners - Learn Docker for a career in software or DevOps engineering. This Docker tutorial teaches you everything you need to get started.

By the end, you will have a deep understanding of the concepts and a great overall big picture of how Docker is used in the whole software development process. 
The course is a mix of animated theoretic explanation and hands-on demo’s to follow along, so you get your first hands-on experience

00:00 What is Docker
05:42 Docker Container Vs. Virtual Machine
09:32 Docker Container & Docker Image
18:50 Why Container
22:40 Docker Image
36:32 Docker Run - Ubuntu Container
29:33 Docker Remove
52:34 DockerFile
57:33 Create Container Using DockerFile
01:08:27 Docker Ignore

#docker #devops

DevOps for Databases: Build & Deploy Database Schema Changes

In this DevOps for Databases tutorial, we'll learn how to build and deploy database schema changes. Learn about Migration vs Model based approaches and the pros and cons of both

In this session, we'll start from the beginning and discuss the decisions you need to make when deciding how you want to build and deploy database schema changes. We'll talk about Migration vs Model based approaches and the pros and cons of both. We'll discuss common gotcha's and review the workflows I've gone through to get to a successful build and deploy pipeline up and running in no time (including a multi-tenant SQL Server database that got its start over 25 years ago).

#devops #database 

Laravel-backup: A Package to Backup Your Laravel App

A modern backup solution for Laravel apps

This Laravel package creates a backup of your application. The backup is a zip file that contains all files in the directories you specify along with a dump of your database. The backup can be stored on any of the filesystems you have configured in Laravel.

Feeling paranoid about backups? No problem! You can backup your application to multiple filesystems at once.

Once installed taking a backup of your files and databases is very easy. Just issue this artisan command:

php artisan backup:run

But we didn't stop there. The package also provides a backup monitor to check the health of your backups. You can be notified via several channels when a problem with one of your backups is found. To avoid using excessive disk space, the package can also clean up old backups.

Installation and usage

This package requires PHP 8.0 and Laravel 8.0 or higher. You'll find installation instructions and full documentation on https://spatie.be/docs/laravel-backup.

Using an older version of PHP / Laravel?

If you are on a PHP version below 8.0 or a Laravel version below 8.0 just use an older version of this package.

Read the extensive documentation on version 3, on version 4, on version 5 and on version 6. We won't introduce new features to v6 and below anymore but we will still fix bugs.

Testing

Run the tests with:

composer test

Changelog

Please see CHANGELOG for more information on what has changed recently.

Contributing

Please see CONTRIBUTING for details.

Security

If you discover any security-related issues, please email security@spatie.be instead of using the issue tracker.

Postcardware

You're free to use this package, but if it makes it to your production environment we highly appreciate you sending us a postcard from your hometown, mentioning which of our package(s) you are using.

Our address is: Spatie, Kruikstraat 22, 2018 Antwerp, Belgium.

We publish all received postcards on our company website.

Credits

• Freek Van der Herten
• All Contributors

And a special thanks to Caneco for the logo ✨

Support us

We invest a lot of resources into creating best in class open source packages. You can support us by buying one of our paid products.

We highly appreciate you sending us a postcard from your hometown, mentioning which of our package(s) you are using. You'll find our address on our contact page. We publish all received postcards on our virtual postcard wall.

Author: Spatie
Source Code: https://github.com/spatie/laravel-backup 
License: MIT license

#laravel #backup #php #devops 

What is DevOps? DevOps Explained

What is DevOps

Learn about the benefits and features of the DevOps lifecycle, and how to use communication and collaboration to deliver better quality code, faster!

✅ DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes.

✅ This speed enables organizations to better serve their customers and compete more effectively in the market.

✈️ Benefits of DevOps

👉Speed: Move at high velocity so you can innovate for customers faster, adapt to changing markets better, and grow more efficient at driving business results.

👉 Rapid Delivery: Increase the frequency and pace of releases so you can innovate and improve your product faster.

👉 Reliability: Ensure the quality of application updates and infrastructure changes so you can reliably deliver at a more rapid pace while maintaining a positive experience for end users.

👉 Scale: Operate and manage your infrastructure and development processes at scale. Automation and consistency help you manage complex or changing systems efficiently and with reduced risk.

Overview

DevOps combines development and operations to increase the efficiency, speed, and security of software development and delivery compared to traditional processes. A more nimble software development lifecycle results in a competitive advantage for businesses and their customers.

DevOps explained

DevOps can be best explained as people working together to conceive, build and deliver secure software at top speed. DevOps practices enable software developers (devs) and operations (ops) teams to accelerate delivery through automation, collaboration, fast feedback, and iterative improvement.

Stemming from an Agile approach to software development, a DevOps delivery process expands on the cross-functional approach of building and shipping applications in a faster and more iterative manner. In adopting a DevOps development process, you are making a decision to improve the flow and value delivery of your application by encouraging a more collaborative environment at all stages of the development cycle.

DevOps represents a change in mindset for IT culture. In building on top of Agile, lean practices, and systems theory, DevOps focuses on incremental development and rapid delivery of software. Success relies on the ability to create a culture of accountability, improved collaboration, empathy, and joint responsibility for business outcomes.

DevOps is a combination of software developers (dev) and operations (ops). It is defined as a software engineering methodology which aims to integrate the work of software development and software operations teams by facilitating a culture of collaboration and shared responsibility.

Core DevOps principles

The DevOps methodology comprises four key principles that guide the effectiveness and efficiency of application development and deployment. These principles, listed below, center on the best aspects of modern software development.

1. Automation of the software development lifecycle
2. Collaboration and communication
3. Continuous improvement and minimization of waste
4. Hyperfocus on user needs with short feedback loops

By adopting these principles, organizations can improve code quality, achieve a faster time to market, and engage in better application planning.

The four phases of DevOps

As DevOps has evolved, so has its complexity. This complexity is driven by two factors:

Organizations are moving from monolithic architectures to microservices architectures. As DevOps matures, organizations need more and more DevOps tools per project.

The result of more projects and more tools per project has been an exponential increase in the number of project-tool integrations. This necessitated a change in the way organizations adopted DevOps tools.

This evolution took place in following four phases:

Phase 1: Bring Your Own DevOps

In the Bring Your Own DevOps phase, each team selected its own tools. This approach caused problems when teams attempted to work together because they were not familiar with the tools of other teams.

Phase 2: Best-in-class DevOps

To address the challenges of using disparate tools, organizations moved to the second phase, Best-in-class DevOps. In this phase, organizations standardized on the same set of tools, with one preferred tool for each stage of the DevOps lifecycle. It helped teams collaborate with one another, but the problem then became moving software changes through the tools for each stage.

Phase 3: Do-it-yourself DevOps

To remedy this problem, organizations adopted Do-it-yourself (DIY) DevOps, building on top of and between their tools. They performed a lot of custom work to integrate their DevOps point solutions together. However, since these tools were developed independently without integration in mind, they never fit quite right. For many organizations, maintaining DIY DevOps was a significant effort and resulted in higher costs, with engineers maintaining tooling integration rather than working on their core software product.

Phase 4: DevOps Platform

A single-application platform approach improves the team experience and business efficiency. GitLab, The DevOps Platform, replaces DIY DevOps, allowing visibility throughout and control over all stages of the DevOps lifecycle.

By empowering all teams – Software, Operations, IT, Security, and Business – to collaboratively plan, build, secure, and deploy software across an end-to-end unified system, GitLab represents a fundamental step-change in realizing the full potential of DevOps. The DevOps Platform is a single application powered by a cohesive user interface, agnostic of self-managed or SaaS deployment. It is built on a single codebase with a unified data store, that allows organizations to resolve the inefficiencies and vulnerabilities of an unreliable DIY toolchain.

As we look ahead to software-led organizations becoming even more distributed and agile, every company will need a DevOps platform to modernize software development and delivery. By making it easier and trusted to adopt the next generation of cloud-native technologies – from microservices to serverless and eventually edge architecture – all companies will be empowered to ship software faster, at maximum efficiency, with security embedded across their end-to-end software supply chain.

How DevOps can benefit from AI/ML?

AI and machine learning (ML) are still maturing in their applications for DevOps, but there is plenty for organizations to take advantage of today, including using the technology to make sense of test data.

AI and ML can find patterns, figure out the coding problems that cause bugs, and alert DevOps teams so they can dig deeper.

Similarly, DevOps teams can use AI and ML to sift through security data from logs and other tools to detect breaches, attacks, and more. Once these issues are found, AI and ML can respond with automated mitigation techniques and alerting.

AI and ML can save developers and operations professionals time by learning how they work best, making suggestions within workflows, and automatically provisioning preferred infrastructure configurations.

What is a DevOps platform?

DevOps brings the human siloes together and a DevOps platform does the same thing for tools. Many teams start their DevOps journey with a disparate collection of tools, all of which have to be maintained and many of which don’t or can’t integrate. A DevOps platform brings tools together in a single application for unparalleled collaboration, visibility, and development velocity. A DevOps platform is how modern software should be created, secured, released, and monitored in a repeatable fashion. A true DevOps platform means teams can iterate faster and innovate together because everyone can contribute.

Benefits of a DevOps Culture

The business value of DevOps and the benefits of a DevOps culture lies in the ability to improve the production environment in order to deliver software faster with continuous improvement. You need the ability to anticipate and respond to industry disruptors without delay. This becomes possible within an Agile software development process where teams are empowered to be autonomous and deliver faster, reducing work in progress. Once this occurs, teams are able to respond to demands at the speed of the market.

There are some fundamental concepts that need to be put into action in order for DevOps to function as designed, including the need to:

Remove institutionalized silos and handoffs that lead to roadblocks and constraints, particularly in instances where the measurements of success for one team is in direct odds with another team’s key performance indicators (KPIs).

Implement a unified tool chain using a single application that allows multiple teams to share and collaborate. This will enable teams to accelerate delivery and provide fast feedback to one another.

What is the goal of DevOps?

DevOps represents a change in mindset for IT culture. In building on top of Agile and lean practices, DevOps focuses on incremental development and rapid delivery of software. Success relies on the ability to create a culture of accountability, improved collaboration, empathy, and joint responsibility for business outcomes.

Adopting a DevOps strategy enables businesses to increase operational efficiencies, deliver better products faster, and reduce security and compliance risk.

The DevOps lifecycle and how DevOps works

The DevOps lifecyle stretches from the beginning of software development through to delivery, maintenance, and security. The 10 lifecycle stages are:

Manage

DevOps closes the loop and incorporates feedback and learnings from the entire lifecycle into your ongoing iteration.

Plan

DevOps describes the work that needs to be done, prioritize it, and track its completion.

Create

DevOps writes code, proposes changes, and discusses these proposals with coworkers.

Verify

DevOps automatically tests code to make sure it works correctly.

Package

DevOps stores the software in a state where it can be reused later.

Secure

DevOps checks whether the software contains vulnerabilities through static and dynamic tests, fuzz testing, and dependency scanning.

Release

DevOps deploys the software to end users.

Configure

DevOps manages infrastructure and software platforms.

Monitor

DevOps sees the impact of the software is on infrastructure and users. It also provides data to help effectively respond to incidents.

Protect

DevOps secures the infrastructure the software is running on by ensuring containers are up to date and locked down.

Some organizations string together a series of tools to gain all of this functionality, but that can be incredibly costly and complex to deploy, manage, and maintain.

DevOps tools, concepts and fundamentals

DevOps covers a wide range of practices across the application lifecycle. Customers start with one or more of these practices in their journey to DevOps success.

How does DevSecOps relate to DevOps?

Security has become an integral part of the software development lifecycle, with much of the security shifting left in the development process. DevSecOps ensures that DevOps teams understand the security and compliance requirements from the very beginning of application creation and can properly protect the integrity of the software.

By integrating security seamlessly into DevOps workflows, organizations gain the visibility and control necessary to meet complex security demands, including vulnerability reporting and auditing. Security teams can ensure that policies are being enforced throughout development and deployment, including critical testing phases.

DevSecOps can be implemented across an array of environments such as on-premises, cloud-native, and hybrid, ensuring maximum control over the entire software development lifecycle.

How is DevOps and CI/CD related?

CI/CD is an essential part of DevOps and any modern software development practice. A purpose-built CI/CD platform can maximize development time by improving an organization’s productivity, increasing efficiency, and streamlining workflows through built-in automation, testing, and collaboration.

As applications grow larger, the features of CI/CD can help decrease development complexity. Adopting other DevOps practices — like shifting left on security and creating tighter feedback loops — helps break down development silos, scale safely, and get the most out of CI/CD.

How does DevOps support the cloud-native approach?

Moving software development to the cloud has so many advantages that more and more companies are adopting cloud-native computing. Building, testing, and deploying applications from the cloud saves money because organizations can scale resources more easily, support faster software shipping, align with business goals, and free up DevOps teams to innovate rather than maintain infrastructure.

Cloud-native application development enables developers and operations teams to work more collaboratively, which results in better software delivered faster.

What is a DevOps engineer?

A DevOps engineer is responsible for all aspects of the software development lifecycle, including communicating critical information to the business and customers. Adhering to DevOps methodologies and principles, they efficiently integrate development processes into workflows, introduce automation where possible, and test and analyze code. They build, evaluate, deploy, and update tools and platforms (including IT infrastructure if necessary). DevOps engineers manage releases, as well as identify and help resolve technical issues for software users.

DevOps engineers require knowledge of a range of programming languages and a strong set of communication skills to be able to collaborate among engineering and business groups.

Benefits of DevOps

Adopting a DevOps mode breaks down barriers so that development and operations teams are no longer siloed and have a more efficient way to work across the entire development and application lifecycle. Without DevOps, organizations experience handoff friction, which delays the delivery of software releases and negatively impacts business results.

The DevOps model is an organization’s answer to increasing operational efficiency, accelerating delivery, and innovating products. Organizations that have implemented a DevOps culture experience the benefits of increased collaboration, fluid responsiveness, and shorter cycle times.

Collaboration

Adopting a DevOps model creates alignment between development and operations teams; handoff friction is reduced and everyone is all in on the same goals and objectives.

Fluid responsiveness

More collaboration leads to real-time feedback and greater efficiency; changes and improvements can be implemented quicker and guesswork is removed.

Shorter cycle time

Improved efficiency and frequent communication between teams shortens cycle time; new code can be released more rapidly while maintaining quality and security.

#devops 

Các Phương Pháp Hay Nhất để Di Chuyển Qua Đám Mây

Tất cả các chuyên gia đều phải tuân theo các phương pháp hay nhất dựa trên trách nhiệm của họ, bất kể họ thực hiện vai trò nào. Đó là vì một lý do: giữ mọi thứ liên quan đến mục tiêu của trách nhiệm đã nói. Tất nhiên, không bao giờ dễ dàng để thực hiện những thực hành như vậy, nhưng nó mang lại niềm hạnh phúc và sự đảm bảo cho kết quả của chúng ta.

Bài đăng này sẽ chia sẻ các phương pháp hay nhất và các yếu tố chính cho chiến lược Di chuyển qua đám mây.

Lập kế hoạch

Tất nhiên, trước khi bắt đầu thực hiện các phương pháp hay nhất, bạn phải thiết lập chiến lược nào bạn sẽ thực hiện cho dự án của mình phù hợp với mục tiêu đó ( Trong trường hợp này là chiến lược nào trong số 7R của Chiến lược di chuyển qua đám mây ).

Bạn phải lập kế hoạch cho từng bước, xác định vai trò của mọi người, xác định mức độ phức tạp của nó, đào tạo bắt buộc và tài nguyên bạn sẽ cần, kiểm kê tài sản đám mây hiện đang sử dụng của bạn, mức độ ưu tiên của việc di chuyển ( dự án ít phức tạp nhất trước ), các công cụ để quan sát, vân vân.

Tôi coi bước này là bước quan trọng nhất. Điều này sẽ cung cấp cho bạn bố cục về người sẽ làm những gì trong quá trình di chuyển và xác định xem có điều gì bị thiếu không.

Di cư từng mảnh

Chúng tôi luôn mong muốn thử các công nghệ và chiến lược mới cho các giải pháp của mình, đặc biệt là khi chuyển sang đám mây.

Tôi hoan nghênh sự nhiệt tình của bạn, nhưng tôi khuyên bạn nên lùi lại một vài bước. Thật thú vị khi di chuyển lên đám mây, nhưng tốt nhất là bạn nên xem dự án của mình từ cấp cao hơn và xác định thứ tự chuyển nó lên đám mây dựa trên sự thiếu phụ thuộc của nó, điều này mang lại khả năng bảo trì dễ dàng cho các dự án của bạn và độ khó của nó .

Điều này có nghĩa là bạn nên di chuyển các mô-đun như vậy để không để lại dấu vết và làm cho các mô-đun khác bị mắc kẹt và không thành công. Đơn giản chỉ cần bắt đầu với những dự án dễ dàng nhất mà không gây ra dự án.

Sẽ có những trường hợp hiếm hoi mà bạn cần phải di chuyển toàn bộ cơ sở hạ tầng của mình trong một lần, vì vậy hãy luôn thực hiện các biện pháp phòng ngừa và các bước cao hơn khi nói đến một cuộc di chuyển lớn.

Đám mây lai

Tôi có thể cung cấp cho bạn quan điểm của tôi về thời điểm sử dụng Hybrid Cloud, nhưng techtarget.com có ​​một cách mô tả tốt hơn về chủ đề mà tôi khuyên bạn nên đọc: Tại đây

Ước tính

Luôn đưa ra một giới hạn khi nói đến nỗ lực và chi phí. Điều này cung cấp cho nhóm của bạn một ý tưởng rõ ràng về những gì đang bị đe dọa và tốc độ cần xử lý khi nó bị phá vỡ trong các giai đoạn khác nhau.

Tất nhiên, chúng tôi không hoàn hảo và chúng tôi có thể vượt quá ước tính đó, nhưng chúng tôi luôn khuyên bạn nên có một cái nhìn rõ ràng về ngày giao hàng và các giới hạn chi phí.

Theo kinh nghiệm của tôi, họ không quan tâm nhiều đến chi phí, nhưng hãy làm như vậy. Sau này có thể họ sẽ phàn nàn về lý do tại sao nó lại đắt như vậy, khi đó bạn có thể cung cấp bằng chứng về một tuyên bố như vậy.

Tôi thích trang web sau đây cung cấp mô tả chi tiết về dự báo Chi phí đám mây: Tại đây

Kế hoạch dự phòng

Bất kể dự án hay mục tiêu của nó, tốt nhất là luôn có một kế hoạch dự phòng, cũng như một kế hoạch khôi phục. Việc triển khai di chuyển của chúng tôi có thể không thành công ở bất kỳ giai đoạn nào và thật tốt nếu có Kế hoạch B, C, v.v. cho những thứ đang hoạt động như chúng phải làm trong giai đoạn nhất định.

Điều này bao gồm quay trở lại ngăn xếp trước đó và cung cấp các bước xử lý các vấn đề từ nhỏ đến lớn.

Hãy để lại nhận xét với kinh nghiệm của bạn về sao lưu, đây là một chủ đề tôi muốn học hỏi thêm từ bạn.

Độ chính xác

Trong hầu hết các trường hợp, chúng tôi bị ràng buộc bởi việc hoàn thành nhiệm vụ với tốc độ nhanh, đây không phải là một tiêu chuẩn tồi để áp dụng nhưng nó mang lại nhiều rủi ro khi di cư quy mô lớn.

Chúng ta phải luôn tập trung vào các thành phần được di chuyển giữ lại mục tiêu chính của chúng, sau khi hoàn thành thì chúng ta có thể tập trung vào các thành phần khác như bảo mật, tốc độ, hiệu suất, v.v.

Thành thật mà nói, đây là tiêu chuẩn mà tôi vẫn đang quen với việc thực hiện đầu tiên trong các dự án di chuyển của mình, nhưng tôi nhận ra mức độ ưu tiên của nó.

Thử nghiệm mọi thứ mà không có lòng thương xót

Đây là bước mà chúng tôi đánh giá cao trực giác và nỗ lực của người kiểm tra.

Các nhà phát triển và kỹ sư luôn tập trung vào khía cạnh kỹ thuật của các mục tiêu của dự án. Điều đó thật tuyệt, nhưng chúng tôi phải luôn tập trung vào tất cả các khía cạnh (không chỉ về mặt kỹ thuật) mà dự án của chúng tôi có thể mang lại.

Đây là nơi những người thử nghiệm sẽ thể hiện con mắt tinh tường của họ và xác định những gì cần sửa chữa và những gì cần tối ưu hóa.

Kiểm toán

Quá trình di chuyển của bạn có thể đã thành công, nhưng nó không loại bỏ khả năng bỏ lỡ một vài bước hoặc thiếu một số biện pháp chưa thực hiện. Bạn nên kiểm tra dự án đã di chuyển của mình theo định kỳ để đảm bảo rằng mọi thứ hoạt động như mong đợi.

Ngoài ra, bạn phải xem xét kiểm toán an ninh. Dự án của bạn có thể đã được bảo mật trên các máy chủ vật lý của bạn, nhưng bạn phải đảm bảo rằng nó tuân thủ các tiêu chuẩn bảo mật trong môi trường đám mây mới của bạn. May mắn thay, tất cả các nhà cung cấp dịch vụ đám mây đều có dịch vụ cho phép bạn làm điều đó một cách dễ dàng.

Để lại nhận xét về bất kỳ công cụ kiểm tra bảo mật nào bạn đã làm việc.

Sự kết luận

Các dự án di chuyển qua đám mây rất tẻ nhạt cũng như chúng rất thú vị và đầy thách thức. Coi đây là một nhiệm vụ lớn với nhiều rủi ro và các khía cạnh kỹ thuật mới, vì vậy chúng tôi phải luôn tuân thủ các phương pháp hay nhất để giữ cho các dự án của mình luôn đẹp và sạch sẽ.

Liên kết: https://medium.com/faun/best-practices-for-cloud-migration-8efce9040876

#cloud #devops

Рекомендации по миграции в облако

Все профессионалы обязаны следовать передовым методам, исходя из своей ответственности, независимо от того, какую роль они выполняют. Это не просто так: сохранить все, что связано с целью указанной ответственности. Конечно, такие практики никогда не бывают легкими, но они приносят блаженство и уверенность в наших результатах.

В этом посте будут представлены лучшие практики и ключевые факторы стратегии миграции в облако.

Планирование

Конечно, прежде чем вы начнете внедрять лучшие практики, вы должны определить, какую стратегию вы будете реализовывать для своего проекта, которая соответствует этой цели ( в данном случае, какая из 7R стратегии миграции в облако ).

Вы должны спланировать каждый шаг, определить роль каждого, определить его сложность, необходимое обучение и ресурсы, которые вам потребуются, инвентарь облачных ресурсов, находящихся в вашем распоряжении в настоящее время, приоритет миграции ( сначала наименее сложный проект ), инструменты для наблюдения, и т.п.

Я считаю этот шаг самым важным. Это даст вам представление о том, кто что будет делать при миграции, и определит, не пропало ли что-то.

Миграция по частям

Мы всегда стремимся опробовать новые технологии и стратегии для наших решений, особенно когда речь идет о миграции в облако.

Я приветствую ваш энтузиазм, но все же рекомендую сделать несколько шагов назад. Мигрировать в облако интересно, но всегда лучше просматривать свой проект с более высокого уровня и определять, в каком порядке его перемещать в облако, исходя из отсутствия в нем зависимостей, что упрощает обслуживание ваших проектов и его сложность. .

Это означает, что вы должны мигрировать такие модули, которые не оставляют следов и не делают другие модули застрявшими и неработоспособными. Просто начните с самых простых проектов, которые не вызывают проектов.

Будут редкие случаи, когда вам потребуется перенести всю инфраструктуру за один раз, поэтому всегда принимайте более строгие меры предосторожности, когда речь идет о большой миграции.

Гибридное облако

Я могу высказать вам свое мнение о том, когда использовать гибридное облако, но на сайте techtarget.com есть гораздо лучшее описание предмета, которое я рекомендую вам прочитать: здесь

Оценивать

Всегда устанавливайте предел, когда дело доходит до усилий и затрат. Это дает вашей команде четкое представление о том, что поставлено на карту, и о том, в каком темпе с этим следует бороться, когда он нарушается на разных этапах.

Конечно, мы не идеальны и можем выйти за рамки этой оценки, но всегда рекомендуется иметь четкое представление о сроках поставки и ограничениях по стоимости.

По моему опыту, они не очень заботятся о расходах, но, пожалуйста, сделайте это. Они, наверное, потом будут жаловаться, почему так дорого, тогда вы можете предоставить доказательства такого утверждения.

Мне нравится следующий сайт с подробным описанием прогнозирования облачных затрат: здесь

Запасной план

Независимо от проекта или его цели, всегда лучше иметь план резервного копирования, а также план восстановления. Наша реализация миграции может дать сбой на любом этапе, и хорошо иметь план B, C и т. д., чтобы все работало так, как предполагается на данном этапе.

Это включает в себя откат к предыдущему стеку и предоставление шагов по устранению незначительных и серьезных проблем.

Пожалуйста, оставьте комментарий с вашим опытом в отношении резервного копирования, это тема, которую я хотел бы узнать от вас больше.

Точность

В большинстве случаев мы связаны практикой выполнения наших задач в быстром темпе, что является неплохим стандартом для применения, но он несет в себе высокий уровень риска при крупномасштабных миграциях.

Мы всегда должны фокусироваться на переносимых компонентах, которые сохраняют свою основную цель, после чего мы можем сосредоточиться на других компонентах, таких как безопасность, скорость, производительность и т. д.

Честно говоря, это стандарт, к которому я все еще привыкаю в первую очередь в своих проектах миграции, но я признаю его приоритет.

Испытайте все без пощады

На этом этапе мы ценим интуицию и усилия нашего тестировщика.

Разработчики и инженеры всегда сосредотачиваются на технической стороне целей проектов. Это здорово, но мы всегда должны фокусироваться на всех аспектах (не только технических), которые может принести наш проект.

Именно здесь тестировщики проявят свой острый глаз и определят, что нужно исправить, а что — оптимизировать.

Аудиторская проверка

Возможно, ваша миграция прошла успешно, но она не исключает возможности пропустить несколько шагов или принять некоторые меры, которые еще предстоит реализовать. Всегда рекомендуется периодически проверять ваш перенесенный проект, чтобы гарантировать, что все работает должным образом.

Кроме того, вы должны рассмотреть аудит безопасности. Ваш проект может быть защищен на ваших физических серверах, но вы должны убедиться, что он соответствует стандартам безопасности в вашей новой облачной среде. К счастью, у всех поставщиков облачных услуг есть служба, которая позволяет вам сделать это с легкостью.

Оставьте комментарий к любому инструменту аудита безопасности, с которым вы работали.

Вывод

Проекты миграции в облако утомительны, а также интересны и сложны. Учитывая, что это большая задача с множеством рисков и новых технических аспектов, мы всегда должны следовать передовым методам, чтобы наши проекты оставались красивыми и чистыми.

Ссылка: https://medium.com/faun/best-practices-for-cloud-migration-8efce9040876

#cloud #devops

雲遷移最佳實踐

所有專業人士都必鬚根據自己的職責遵循最佳實踐，無論他們扮演什麼角色。它的存在是有原因的：保持與所述責任目標相關的一切。當然，實施這樣的做法絕非易事，但它確實為我們的成果帶來了幸福和保證。

這篇文章將分享雲遷移策略的最佳實踐和關鍵因素。

規劃

當然，在開始實施最佳實踐之前，您必須確定將為符合該目標的項目實施哪種策略（在這種情況下，雲遷移策略的 7R 中的哪一個）。

您必須計劃每個步驟，確定每個人的角色，確定其複雜性、所需的培訓和您需要的資源、當前可供您使用的雲資產清單、遷移的優先級（最不復雜的項目優先）、可觀察性工具，等等

我認為這一步是最重要的一步。這將為您提供誰將在遷移中做什麼的佈局，並確定是否缺少某些內容。

一點一點地遷移

我們總是渴望為我們的解決方案嘗試新技術和策略，尤其是在遷移到雲方面。

我為你的熱情鼓掌，但我建議你退後幾步。遷移到雲是令人興奮的，但是最好從更高的層次查看您的項目，並根據其缺乏依賴性來確定將其遷移到雲的順序，這為您的項目帶來了易維護性和難度.

這意味著您應該遷移這樣的模塊，這些模塊不會留下痕跡，並使其他模塊陷入困境和失敗。只需從不會導致項目的最簡單的項目開始。

在極少數情況下，您需要一次性遷移整個基礎架構，因此在進行大規模遷移時，請始終採取更高的預防措施和步驟。

混合雲

關於何時使用混合雲，我可以給你我的觀點，但是 techtarget.com 對這個主題有更好的描述，我建議你閱讀：這裡

估計

當涉及到工作量和成本時，請始終設定一個限制。這讓您的團隊清楚地了解什麼是危險的，以及在不同階段發生故障時應該處理的速度。

當然，我們並不完美，我們可能會超出這個估計，但始終建議清楚地了解交貨日期和成本限制。

根據我的經驗，他們不太關心成本，但請這樣做。他們稍後可能會抱怨為什麼它如此昂貴，然後您可以提供有關此類聲明的證據。

我喜歡以下詳細描述云成本預測的網站：這裡

後備方案

無論項目或其目標如何，最好有一個備份計劃以及恢復計劃。我們的遷移實施可能在任何階段都失敗，最好有一個計劃 B、C 等來讓事情在給定階段按預期運行。

這包括回滾到以前的堆棧並提供處理從小到大問題的步驟。

請留下您在備份方面的經驗的評論，這是我想向您了解更多信息的主題。

精確

在大多數情況下，我們受制於快速完成任務的做法，這不是一個糟糕的標準，但它確實為大規模遷移帶來了高風險。

我們必須始終專注於保留其主要目標的遷移組件，一旦完成，我們就可以專注於其他組件，例如安全性、速度、性能等。

老實說，這是我仍然習慣於在我的遷移項目中首先實施的標準，但我確實認識到它的優先級。

毫無憐憫地測試一切

這是我們欣賞測試人員的直覺和努力的步驟。

開發人員和工程師始終關注手頭項目目標的技術方面。這很棒，但我們必須始終關注我們項目可能帶來的所有方面（不僅是技術方面）。

測試人員將在這裡發揮他們敏銳的眼光，確定哪些需要修復，哪些需要優化。

審計

您的遷移可能已經成功，但它不會排除錯過幾個步驟或缺少一些尚未實施的措施的可能性。始終建議定期審核您遷移的項目，以確保一切按預期工作。

此外，您必須考慮安全審計。您的項目在物理服務器上可能是安全的，但您必須確保它符合新雲環境中的安全標準。幸運的是，所有云服務提供商都有一項服務可以讓您輕鬆做到這一點。

對您使用過的任何安全審計工具發表評論。

結論

雲遷移項目既乏味又令人興奮且具有挑戰性。考慮到這是一項艱鉅的任務，具有許多風險和新技術方面，因此我們必須始終遵循最佳實踐以保持我們的項目乾淨整潔。

鏈接：https ://medium.com/faun/best-practices-for-cloud-migration-8efce9040876

#cloud #devops

Meilleures Pratiques Pour La Migration Vers Le Cloud

Tous les professionnels sont tenus de suivre les meilleures pratiques en fonction de leur responsabilité, quel que soit le rôle qu'ils exercent. Il est là pour une raison : garder tout ce qui est lié à l'objectif de ladite responsabilité. Bien sûr, il n'est jamais facile de mettre en place de telles pratiques, mais cela apporte bonheur et assurance de nos résultats.

Cet article partagera les meilleures pratiques et les facteurs clés de la stratégie de migration vers le cloud.

Planification

Bien sûr, avant de commencer à mettre en œuvre les meilleures pratiques, vous devez établir quelle stratégie vous allez mettre en œuvre pour votre projet qui est conforme à cet objectif ( dans ce cas, lequel des 7R de la stratégie de migration vers le cloud ).

Vous devez planifier chaque étape, déterminer le rôle de chacun, déterminer sa complexité, la formation requise, et les ressources dont vous aurez besoin, l'inventaire des actifs cloud actuellement à votre disposition, la priorité de la migration ( le projet le moins compliqué en premier ), les outils d'observabilité, etc.

Je considère que cette étape est la plus importante. Cela vous donnera la disposition de qui va faire quoi dans la migration et déterminera s'il manque quelque chose.

Migrer morceau par morceau

Nous sommes toujours impatients d'essayer de nouvelles technologies et stratégies pour nos solutions, en particulier lorsqu'il s'agit de migrer vers le cloud.

J'applaudis votre enthousiasme, mais je recommande de prendre quelques pas en arrière. C'est excitant de migrer vers le cloud, mais il est toujours préférable de voir votre projet d'un niveau supérieur et de déterminer dans quel ordre le déplacer vers le cloud en fonction de son manque de dépendances qui apporte une facilité de maintenabilité à vos projets et sa difficulté .

Cela signifie que vous devez migrer ces modules qui ne laissent pas de traces et qui bloquent et échouent les autres modules. Commencez simplement par les projets les plus faciles qui ne causent pas de projets.

Il y aura de rares occasions où vous aurez besoin de migrer toute votre infrastructure en une seule fois, alors prenez toujours des précautions et des étapes plus élevées lorsqu'il s'agit d'une migration importante.

Nuage hybride

Je peux vous donner mon point de vue sur le moment d'utiliser Hybrid Cloud, mais techtarget.com a une bien meilleure description du sujet que je vous recommande de lire : Ici

Estimation

Fixez toujours une limite en matière d'efforts et de coûts. Cela donne à votre équipe une idée claire de ce qui est en jeu et du rythme à suivre lorsqu'il est divisé en différentes étapes.

Bien sûr, nous ne sommes pas parfaits et nous pouvons aller au-delà de cette estimation, mais il est toujours recommandé d'avoir une vision claire de la date de livraison et des limites de coût.

D'après mon expérience, ils ne se soucient pas beaucoup des coûts, mais s'il vous plaît, faites-le. Ils se plaindront probablement plus tard de la raison pour laquelle c'est si cher, alors vous pourrez fournir des preuves d'une telle affirmation.

J'apprécie le site suivant qui donne une description détaillée de la prévision des coûts du cloud : Ici

Plan de sauvegarde

Peu importe le projet ou son objectif, il est toujours préférable d'avoir un plan de sauvegarde, ainsi qu'un plan de reprise. Notre mise en œuvre de la migration peut échouer à n'importe quelle étape et il est bon d'avoir un plan B, C, etc. pour que les choses fonctionnent comme elles sont censées le faire à l'étape donnée.

Cela inclut le retour à une pile précédente et la fourniture d'étapes sur la gestion des problèmes mineurs à majeurs.

Veuillez laisser un commentaire avec votre expérience concernant les sauvegardes, c'est un sujet sur lequel j'aimerais en savoir plus.

Précision

Dans la plupart des cas, nous sommes liés par la pratique de terminer nos tâches à un rythme rapide, ce n'est pas une mauvaise norme à appliquer mais cela apporte une marge de risque élevée sur les migrations à grande échelle.

Nous devons toujours nous concentrer sur les composants en cours de migration qui conservent leur objectif principal, une fois cela fait, nous pouvons nous concentrer sur d'autres composants tels que la sécurité, la vitesse, les performances, etc.

Pour être honnête, c'est une norme que je m'habitue encore à mettre en œuvre en premier dans mes projets de migration, mais je reconnais sa priorité.

Tout tester sans pitié

C'est l'étape où nous apprécions l'intuition et l'effort de notre testeur.

Les développeurs et les ingénieurs se concentrent toujours sur l'aspect technique des objectifs des projets en cours. C'est formidable, mais nous devons toujours nous concentrer sur tous les aspects (pas seulement la technique) que notre projet peut apporter.

C'est là que les testeurs apporteront leur œil attentif et détermineront ce qui doit être corrigé et ce qui doit être optimisé.

Audit

Votre migration a peut-être réussi, mais cela n'exclut pas la possibilité de manquer quelques étapes ou de manquer quelques mesures à mettre en œuvre. Il est toujours recommandé d'auditer périodiquement votre projet migré, ce qui garantira que tout fonctionne comme prévu.

En outre, vous devez envisager des audits de sécurité. Votre projet a peut-être été sécurisé sur vos serveurs physiques, mais vous devez vous assurer qu'il est conforme aux normes de sécurité de votre nouvel environnement cloud. Heureusement, tous les fournisseurs de services cloud ont un service qui vous permet de le faire facilement.

Laissez un commentaire sur tout outil d'audit de sécurité avec lequel vous avez travaillé.

Conclusion

Les projets de migration vers le cloud sont fastidieux, passionnants et stimulants. Considérant qu'il s'agit d'une tâche importante dans votre assiette avec de nombreux risques et de nouveaux aspects techniques, nous devons toujours suivre les meilleures pratiques pour que nos projets restent beaux et propres.

Lien : https://medium.com/faun/best-practices-for-cloud-migration-8efce9040876

#cloud #devops

Top Các Giải Pháp Elastic Beanstalk Cho Công Ty Khởi Nghiệp Năm 2022

Các nhà phát triển tại các công ty khởi nghiệp hầu như luôn phải đối mặt với câu hỏi về cách hiệu quả nhất về chi phí để nhận được các lợi ích của đám mây mà không cần phải quản lý các hệ thống cơ bản. Nhiều năm trước, khi chúng tôi vẫn đang xây dựng các tảng đá nguyên khối và sử dụng các phiên bản EC2 , Elastic Beanstalk (hoặc Google App Engine và Azure App Service) là một lựa chọn hấp dẫn cho các công ty khởi nghiệp trẻ muốn triển khai nhanh chóng.

Ngay cả khi đó, Elastic Beanstalk (EB) chỉ phù hợp với các ứng dụng không quan trọng với nhiệm vụ yêu cầu cấu hình và triển khai tiêu chuẩn. (Dưới đây là một số tài khoản của các nhà phát triển thực sự bị bỏng tay với EB). Bên cạnh đó, Elastic Beanstalk đã không thấy bản nâng cấp lớn trong một thời gian , vì vậy bạn có nên sử dụng nó ngay cả cho các ứng dụng không quan trọng nữa không? Những lựa chọn thay thế hiện đại cho Elastic Beanstalk vào năm 2022 là gì?

Phần lớn thông tin hiện có về các lựa chọn thay thế của EB hoặc liệt kê các PaaS kế thừa tương đương từ các nhà cung cấp đám mây khác hoặc so sánh với Heroku trì trệ. Và hiếm khi họ cân nhắc các lựa chọn thay thế từ quan điểm của các công ty khởi nghiệp với một đội tinh gọn hoặc không có hoạt động nào cả. Bài đăng này cố gắng liệt kê và so sánh các tùy chọn với Elastic Beanstalk vào năm 2022. Nó sẽ hữu ích cho bạn nếu:

• Bạn là một công ty khởi nghiệp đang phát triển cần xây dựng và mở rộng quy mô các ứng dụng quan trọng - các khía cạnh như thời gian triển khai, độ trễ và khắc phục sự cố là rất quan trọng đối với bạn.
• Bạn hiện đã ghép cơ sở hạ tầng và quy trình của mình theo cách thủ công. Và bạn đang đánh giá PaaS nào phù hợp nhất với bạn.
• Bạn đã sử dụng EB nhưng muốn chuyển khỏi nó bởi vì bây giờ, khi bạn đang mở rộng quy mô, những hạn chế của EB đang làm hại bạn - triển khai không ổn định & chậm và thiếu minh bạch xung quanh các lỗi và cập nhật, có thể kể đến một vài cái tên.
• Bạn muốn chạy ứng dụng của mình mà không cần thuê một nhóm hoạt động hoặc chỉ với một nhóm hoạt động tinh gọn.

Bây giờ, chúng tôi nhận ra rằng chỉ đọc bài đăng này sẽ không giúp bạn thu hẹp PaaS cho công ty khởi nghiệp của mình - bởi vì người ta chỉ có thể quyết định sau khi xem xét các sắc thái của trường hợp sử dụng của một người, bộ kỹ năng của nhóm và các chi phí liên quan. Tuy nhiên, hy vọng của chúng tôi là blog này sẽ giúp bạn điều hướng thông qua các công nghệ khác nhau có thể giúp bạn giải quyết cho quy mô ngày càng tăng của mình.

Các giải pháp thay thế không tạo ra sự cắt giảm

Do đó, bài viết này không công nhận những điều sau đây là các lựa chọn thay thế EB thực tế:

• Heroku : Mặc dù có kinh nghiệm dành cho nhà phát triển chưa từng có, chúng tôi khuyên bạn không nên bắt đầu sử dụng Heroku nữa vì nó thường đắt hơn nhiều so với bất kỳ lựa chọn thay thế nào khác và nó đã không phát hành bất kỳ bản nâng cấp đáng chú ý nào trong nhiều năm. Ví dụ: nó vẫn không hỗ trợ HTTP / 2 .
• IaaS : IaaS yêu cầu bạn định cấu hình máy chủ của mình, chỉ định quy tắc mạng, quản lý tính năng tự động chia tỷ lệ, cập nhật bảo mật, v.v., tất cả đều do bạn tự làm. Mặc dù phương pháp này mang lại cho bạn nhiều quyền kiểm soát và linh hoạt hơn so với một PaaS như Elastic Beanstalk, nhưng việc thuê một nhóm hoạt động chuyên ngành lớn sẽ phải trả một chi phí đáng kể.
• FaaS : Faas thích hợp để chạy các công việc không đồng bộ và các ứng dụng hướng sự kiện như RESTful. Và trong nhiều trường hợp sử dụng này, FaaS là ​​một ứng dụng phụ của ứng dụng cốt lõi của bạn, không phải ứng dụng cốt lõi. Đối với các trường hợp sử dụng thân thiện với FaaS, nó cũng có thể là ứng dụng cốt lõi của bạn khi bạn mới bắt đầu và nhận được các đỉnh lưu lượng không nhất quán. Nhưng bài đăng này đề cập đến các công ty khởi nghiệp có các trường hợp sử dụng rộng hơn nhiều so với các trường hợp sử dụng phù hợp với FaaS.

Chuyển sang Lựa chọn thay thế.

PaaS kế thừa được quản lý hoàn toàn trên các đám mây công cộng

Có 2 giải pháp PaaS, mỗi giải pháp của hai nhà cung cấp đám mây hàng đầu khác: Google và Microsoft, gần tương đương với Elastic Beanstalk:

• Công cụ ứng dụng của Google
• Dịch vụ ứng dụng của Azure

Lợi ích chính của việc sử dụng dịch vụ PaaS của bất kỳ nhà cung cấp dịch vụ đám mây nào, có thể là Elastic Beanstalk, App Engine hoặc App Service, là thời gian đưa ra thị trường nhanh hơn bằng cách loại bỏ chi phí xử lý chi tiết về triển khai, cung cấp dung lượng, cân bằng tải, bảo mật, mở rộng và theo dõi sức khỏe ứng dụng.

Vì vậy, làm thế nào để bạn đánh giá chúng so với nhau?

Công cụ ứng dụng của Google

Mặc dù nó giàu tính năng và đã được thử nghiệm chiến đấu, nhưng giờ đây bản thân Google coi App Engine là một sản phẩm kế thừa . Chúng tôi đã bao gồm nó như một giải pháp thay thế vì một số bạn có thể đã hỏi chúng tôi tại sao nếu chúng tôi không làm như vậy. Ngày nay, bản thân Google khuyến nghị các nhà phát triển App Engine chuyển sang Cloud Run hiện đại hơn - dịch vụ chị em với App Engine. (Thông tin thêm về nó sau)

Dịch vụ ứng dụng Azure

Nếu ứng dụng của bạn sử dụng các công nghệ của Microsoft như .NET, thì việc chạy ứng dụng của bạn trên App Service sẽ dễ dàng hơn so với EB hoặc App Engine . Nhưng một lần nữa, tương tự như Elastic Beanstalk và App Engine, đó là một PaaS kế thừa. Tốt hơn hết bạn nên đánh giá các dịch vụ PaaS hiện đại hơn của Microsoft.

Đề nghị của chúng tôi

Elastic Beanstalk, App Engine và App Service đều phù hợp nhất để chạy các ứng dụng web đơn giản hoặc phần phụ trợ ứng dụng dành cho thiết bị di động trong nền tảng không máy chủ. Đây cũng là những dịch vụ kế thừa. Mặc dù chúng nhận được các bản cập nhật thường xuyên, nhưng một vài tính năng đáng chú ý đã được thêm vào chúng trong vài năm qua. Cho dù bạn đang tìm cách chọn PaaS đầu tiên của mình hay một giải pháp thay thế cho thiết lập Elastic Beanstalk hiện có, chúng tôi thực sự khuyên bạn nên tiếp tục đọc để tìm hiểu thêm về các tùy chọn hiện đại được quản lý hoàn toàn và không có máy chủ cũng có thể chống lại trong tương lai.

Tuy nhiên, nếu bạn vẫn tin rằng một trong những PaaS này là vừa đủ cho trường hợp sử dụng của bạn và muốn chọn một trong số chúng, thì đây là những gì chúng tôi phải nói. Các tính năng hoặc triển khai cơ bản sẽ hiếm khi quyết định bạn chọn cái nào vì bạn có thể hoàn thành bất kỳ trường hợp sử dụng nào với bất kỳ cách nào trong số chúng (có hoặc không có giải pháp thay thế). Vì vậy, sẽ có hai cách suy nghĩ về quyết định của bạn:

• Nếu bạn đã sử dụng Elastic Beanstalk của AWS, việc di chuyển sang một đám mây khác (mặc dù không phải là chưa từng thấy) chỉ dành cho PaaS (App Engine hoặc App Service) của họ hiếm khi là lựa chọn lý tưởng trừ khi chuyên môn của nhóm bạn hiện là với một nhà cung cấp đám mây khác hoặc có một sự khác biệt đáng kể về chi phí trong việc sử dụng các tính năng mà bạn quan tâm.
• Nếu bạn đang chọn PaaS đầu tiên của mình, hãy thực hiện phân tích lợi ích chi phí của các dịch vụ bạn muốn chạy, cách chúng sẽ tương tác và trải nghiệm của nhóm bạn với nhà cung cấp đám mây cụ thể đó.

Lưu ý: Các nhà cung cấp đám mây nhỏ hơn khác như DigitalOcean cung cấp các dịch vụ tương tự với khả năng hỗ trợ khách hàng tốt hơn nhiều và với chi phí thấp hơn, nhưng phạm vi các trường hợp sử dụng mà bạn có thể xử lý bị hạn chế so với PaaS của các nhà cung cấp dịch vụ đám mây khác.

Chuyển sang các lựa chọn thay thế hiện đại .

PaaS trên đám mây riêng tư

Một lớp các dịch vụ PaaS gần đây như Fly , Render và Railway đã mọc lên để lấp đầy khoảng trống do Heroku trì trệ và bối cảnh ngày càng phức tạp của các dịch vụ của nhà cung cấp đám mây công cộng.

Bay so với Kết xuất so với Đường sắt

Mặc dù Render, Fly và Railway thường đọ sức với nhau khi tìm kiếm trải nghiệm giống Heroku, nhưng chúng không phải là những thứ gần như tương đương. Vì vậy, trước tiên, hãy so sánh chúng với nhau:

• Render giống Heroku hơn nhiều, còn được đánh bóng trong trải nghiệm và khả năng dành cho nhà phát triển của nó như tài liệu, bảng điều khiển, CLI, v.v., hơn Fly hoặc Railway.
• Render hỗ trợ ít khu vực hơn Fly . Không có thông tin về các khu vực được hỗ trợ bởi Đường sắt.
• Giá của Fly and Render rất phức tạp. Thật thú vị, giá của Đường sắt dựa trên mức sử dụng với cấp miễn phí rộng rãi.
• (Hiện tại) Cả Fly và Render đều cung cấp Postgres được quản lý hoàn toàn. Đường sắt hỗ trợ tích hợp no-config với Postgres và một số cơ sở dữ liệu khác, nhưng không có tích hợp nào trong số này được quản lý đầy đủ.
• Không có hàng đợi hỗ trợ Fly, Render hoặc Railway. Vì vậy, chúng không phù hợp với các trường hợp sử dụng yêu cầu các khả năng này.
• Cả Render và Railway đều hỗ trợ Monorepos; Fly không.

Đề nghị của chúng tôi

Nếu bạn đã sử dụng Elastic Beanstalk và đang cân nhắc việc di chuyển để linh hoạt hơn hoặc để quản lý quy mô hơn, thì không có Fly, Render hoặc Railway nào phù hợp. Trên thực tế, chúng có thể hạn chế hơn.

Nhưng nếu bạn đang tìm kiếm PaaS đầu tiên của mình, bạn nên biết những điều sau:

• Fly được tối ưu hóa cho các ứng dụng tiên tiến như không có PaaS nào khác và là ứng cử viên hàng đầu nếu bạn đang xây dựng một ứng dụng như vậy.
• (Hiện tại) Fly, Render hoặc Railyway rất phù hợp cho các trường hợp sử dụng như chạy trang web tĩnh, xây dựng ứng dụng CRUD đơn giản hoặc ứng dụng không yêu cầu cơ sở dữ liệu (giả sử thời gian chạy của bạn được hỗ trợ).
• Vì tất cả chúng đều hỗ trợ hình ảnh docker, khóa của bạn khá hạn chế đối với các tính năng độc quyền của chúng. Vì vậy, khóa trong không nên là một mối quan tâm trong khi đánh giá chúng.
• Trừ khi bạn đang tìm cách sử dụng các tính năng chỉ dành cho Fly, còn lại thì Render và Railway thân thiện với nhà phát triển hơn và có thể phù hợp hơn trong tương lai.
• Định giá đơn giản của Đường sắt tạo ra một trường hợp để thử nó trước bất kỳ ai khác.

PaaS gốc vùng chứa trên đám mây công cộng

Container-native PaaS là ​​một dịch vụ không có máy chủ, được quản lý hoàn toàn để triển khai các ứng dụng và API được container hóa.

Giống như PaaS cũ, bạn có thể cung cấp mã nguồn hoặc hình ảnh vùng chứa. Họ đảm nhận việc triển khai, nâng cấp, cân bằng tải, mở rộng quy mô, bảo mật, v.v. để bạn có thể tập trung vào việc mang lại giá trị kinh doanh.

Nhưng không giống như PaaS cũ , chúng được tối ưu hóa để xây dựng và lưu trữ không chỉ các ứng dụng web và di động mà còn cả các API, dịch vụ vi mô, các quy trình chạy dài, các tác vụ nền và các ứng dụng hướng sự kiện.

Có ba PaaS gốc được quản lý hoàn toàn theo vùng chứa đáng chú ý trên các đám mây công cộng: Google Cloud Run (thường có sẵn từ tháng 11 năm 2019), AWS App Runner ( ra mắt vào tháng 5 năm 2021 ) và Ứng dụng vùng chứa Azure (thường khả dụng - tháng 5 năm 2022).

Ứng dụng Cloud Run so với App Runner và Container

• Mặc dù tất cả chúng đều có thể triển khai từ cả hình ảnh vùng chứa và mã nguồn, nhưng chúng có những ràng buộc khác nhau về loại hình ảnh, kho mã nguồn và thời gian chạy ngôn ngữ được hỗ trợ.
• Cloud Run hỗ trợ nhiều ngôn ngữ hơn Ứng dụng vùng chứa và Trình chạy ứng dụng .
• Ứng dụng Cloud Run và Container hỗ trợ HTTP / 2, WebSockets và gRPC, nhưng App Runner thì không .
• Ứng dụng Cloud Run và Container hỗ trợ giảm tỷ lệ xuống 0, trong khi App Runner thì không .
• Hỗ trợ cho các công việc nền không lý tưởng trong App Runner và Cloud Run , nhưng Container Apps tuyên bố sẽ hỗ trợ chúng.
• Cloud run hỗ trợ triển khai xanh lam / xanh lá cây, hoàng yến và lăn . Các ứng dụng vùng chứa chỉ hỗ trợ triển khai màu xanh lam / xanh lá cây và canary . Nhưng App runner không hỗ trợ bất kỳ cái nào trong số này.
• Ứng dụng vùng chứa hỗ trợ nhiều vùng chứa trong một dịch vụ, nhưng Cloud Run và App Runner thì không.
• Khóa lại
• Hầu như không có khóa trong Cloud Run: Nó dựa trên KNative, là mã nguồn mở. Cloud Run chỉ là một lớp trên cùng của KNative, là mã nguồn mở. Vì vậy, bạn có thể triển khai vùng chứa của mình trong bất kỳ cụm K8S nào bằng cách sử dụng các định nghĩa KNative.
• Ứng dụng vùng chứa: Khoản đầu tư duy nhất của bạn là tạo hình ảnh vùng chứa và sau đó chạy một vài lệnh để triển khai nó. Ngoài ra, nó được cung cấp bởi Kubernetes, một nguồn mở. Vì vậy, nếu bạn chọn di chuyển, bạn sẽ có thể làm điều đó tương đối dễ dàng.
• App Runner: Nó chạy trên ECS Fargate, là một dịch vụ AWS độc quyền, nhưng khoản đầu tư của bạn bị giới hạn trong việc cung cấp hình ảnh vùng chứa trong khi nó lo phần còn lại (là một PaaS). Vì vậy, sẽ có rất ít nỗ lực bị mất nếu bạn chọn di cư.
• Tính năng tự động thay đổi tỷ lệ trong Cloud Run hoạt động hiệu quả - mà bạn không cần phải chỉ định bất kỳ quy tắc nào - dựa trên hành vi mặc định của nó là tạo bản sao cho mỗi 100 yêu cầu đồng thời. Tuy nhiên, cả Ứng dụng chạy ứng dụng và Ứng dụng vùng chứa đều yêu cầu bạn chỉ định quy tắc tự động điều chỉnh tỷ lệ.

Đề nghị của chúng tôi

• Mỗi App Runner, Container Apps, Cloud Run, Fly và Render đều là những PaaS tương đối mới và do đó chưa được thử nghiệm chiến đấu.
• Mặc dù tất cả chúng đều tương đối mới, Fly và Render chắc chắn sẽ bị hạn chế hơn so với các đối tác đám mây công cộng gốc vùng chứa của chúng vì các đám mây công cộng có một loạt các dịch vụ mà bạn có thể sử dụng để giải quyết bất kỳ trường hợp sử dụng nào. Nó có thể không phải là một cách giải quyết gọn gàng, nhưng nó sẽ không cản trở bạn. Ngược lại, một khi bạn chạm vào tường với khả năng của chúng bằng Fly hoặc Render, bạn phải di chuyển ra khỏi chúng.
• Nếu bạn đang tìm kiếm PaaS đầu tiên của mình, tất cả chúng phải được đánh giá dựa trên tình huống sử dụng và kỹ năng nhóm của bạn.
• Tuy nhiên, nếu bạn đang tìm cách di chuyển khỏi Elastic Beanstalk để linh hoạt hơn trên quy mô, hãy đánh giá App Runner và AWS's CaaS (sẽ tìm hiểu thêm ở phần sau) .

Vùng chứa dưới dạng dịch vụ (CaaS) trên đám mây công cộng

Tất cả các tùy chọn PaaS ở trên cho phép bạn phát triển và triển khai các ứng dụng mà không phải chịu gánh nặng về xây dựng, quản lý và duy trì cơ sở hạ tầng. PaaS gốc vùng chứa gần giống như CaaS, ngoại trừ trong một số trường hợp, như chúng ta sẽ thấy, CaaS cung cấp nhiều quyền kiểm soát hơn.

Sự trừu tượng của PaaS gốc vùng chứa này hoạt động tuyệt vời ngay từ đầu đối với hầu hết các công ty khởi nghiệp, nhưng nếu tại một thời điểm nào đó bạn yêu cầu kiểm soát nhiều hơn, bạn sẽ cần phải đánh giá dịch vụ CaaS đáng chú ý duy nhất khác: ECS. Chúng ta hãy xem xét một số ưu và nhược điểm đáng chú ý của nó:

AWS ECS (có hoặc không có Fargate)

• Yêu cầu hàng chục mảnh được lắp ráp trước khi bạn có thể triển khai bất cứ thứ gì trên đó. Vì vậy, trải nghiệm người dùng là khó chịu.
• Việc thiết lập tự động mở rộng quy mô trên ECS rất phức tạp (giống như phần còn lại của trải nghiệm sử dụng nó).
• Hoàn toàn độc quyền và buộc bạn phải hoàn toàn dựa vào AWS; số lượng tài nguyên bạn cần tạo và định dạng để viết định nghĩa ứng dụng đảm bảo rằng chúng tôi bị khóa trong AWS. Bạn sẽ cảm thấy rất khó để chuyển ra ngoài nếu bạn chọn nó. Nhưng một lần nữa, quá trình khóa cần được đánh giá dựa trên những gì nó tạo ra dễ dàng cho bạn.
• Bản chất độc quyền của nó cũng dẫn đến việc nó thiếu sự hỗ trợ của cộng đồng.

Lưu ý: Chúng tôi không bao gồm Phiên bản vùng chứa Azure (ACI) làm giải pháp thay thế vì nó không hỗ trợ tự động mở rộng quy mô theo chiều ngang. Việc chia tỷ lệ dọc cũng hoàn toàn là thủ công. Tất cả những gì bạn có thể làm là chạy các phiên bản đơn lẻ được tách biệt với nhau. Do đó, ACI không thể được sử dụng trong sản xuất cho bất kỳ ứng dụng nào trừ khi một phiên bản ứng dụng duy nhất là đủ trong trường hợp sử dụng của bạn.

Đề nghị của chúng tôi

• Bất kể trường hợp sử dụng của bạn là gì, hãy bỏ qua ACI hoàn toàn.
• Nếu bạn đã sử dụng AWS và trường hợp sử dụng của bạn không phù hợp với Kubernetes, hãy đánh giá ECS so với App Runner để chạy các vùng chứa được quản lý.
• ECS cung cấp tính linh hoạt hơn so với App Runner với chi phí bạn phải làm nhiều công việc quản trị hơn. Ví dụ: nó có thể chạy nhiều vùng chứa trong một dịch vụ trong khi App Runner thì không.
• Trải nghiệm nhà phát triển cấp độ phụ của ECS yêu cầu thời gian thiết lập đáng kể. Bạn nên chuẩn bị tâm lý cho điều đó.
• Nếu mục tiêu của bạn là thuê 0 nhân viên thì không nên sử dụng ECS.
• Nếu AWS không phải là một hạn chế, thì Cloud Run là ứng dụng thân thiện với nhà phát triển nhất để triển khai các ứng dụng được container hóa. Nó đi kèm với ít khóa nhất và là cách tiện lợi nhất để chạy các vùng chứa không máy chủ và được quản lý. Chúng tôi thực sự khuyên bạn nên đánh giá nó.

Kubernetes dưới dạng Dịch vụ (KaaS) hoặc Kubernetes được quản lý

Về mặt logic, CaaS sẽ là bước tiếp theo nếu người ta muốn chuyển ra khỏi PaaS để có tính linh hoạt và khả năng mở rộng. Nhưng một số trường hợp sử dụng cũng đảm bảo xem xét Kubernetes. Các dịch vụ KaaS hoặc Managed Kubernetes, chẳng hạn như GKE , EKS và AKS , loại bỏ việc quản lý mặt phẳng điều khiển và do đó dễ làm việc hơn so với việc sử dụng Kubernetes trực tiếp.

Nhưng bạn nên biết những gì về nó để có thể đưa ra quyết định sáng suốt hơn?

• Kubernetes là một hệ thống điều phối vùng chứa mã nguồn mở. CaaS, giống như ECS, có một hệ thống điều phối vùng chứa độc quyền - nhược điểm chính của chúng đối với Kubernetes. (Mặc dù vậy, các ứng dụng Cloud Run và Azure Container không bị lỗi này vì Kubernetes cung cấp năng lượng cho chúng)
• Điều tuyệt vời về KaaS là ​​Kubernetes - là mã nguồn mở, có sự hỗ trợ cộng đồng đáng kể và một hệ sinh thái các công cụ đang phát triển để giải quyết các trường hợp sử dụng phổ biến - vì vậy, có rất ít khóa và khả năng mở rộng vô hạn.
• Trong khi KaaS đơn giản hóa việc quản lý mặt phẳng điều khiển, nó vẫn để lại quyền quản lý các nút công nhân - chẳng hạn như nâng cấp và kết nối mạng cho bạn. Chi phí khổng lồ đó đòi hỏi một nhóm chuyên dụng với kiến ​​thức Kubernetes chuyên biệt.

Đề nghị của chúng tôi

• Đánh giá xem Kubernetes có được yêu cầu cho trường hợp sử dụng của bạn hay không hay các vùng chứa sẽ hoạt động tốt cho bạn (thông qua PaaS hoặc CaaS dành cho vùng chứa).
• Nếu bạn quyết định tiếp tục với Kubernetes, hãy đánh giá xem bạn có nhóm để vận hành KaaS như GKE, EKS và AKS hay không.
• Nói chung, GKE là KaaS trưởng thành nhất tính đến ngày hôm nay, và cũng là những gì chúng tôi muốn giới thiệu.

Nếu bạn không có thời gian và nguồn lực để hỗ trợ KaaS ngày hôm nay nhưng quyết định đi theo con đường Kubernetes, thì có thể có điểm trung gian giữa KaaS, CaaS và PaaS.

Nền tảng trung gian giữa PaaS, CaaS và KaaS

Nền tảng trung gian giữa PaaS, CaaS và Kaas sẽ lấy những đặc điểm tốt nhất của từng loại và sẽ không có những giới hạn tương ứng.

• Không giống như KaaS hoặc CaaS, và chính xác như PaaS - nó sẽ được quản lý hoàn toàn và không có máy chủ.
• Không giống như CaaS hoặc PaaS độc quyền, nó dựa trên một công cụ mã nguồn mở như Kubernetes.
• Điều đó không ràng buộc bạn với một nhà cung cấp đám mây cụ thể hoặc các công cụ của nó.
• Điều đó mang lại cho bạn không gian để tích hợp và tận dụng hệ sinh thái rộng lớn của các công cụ của bên thứ ba để ghi nhật ký, giám sát, lưu trữ, v.v.

Tại Argonaut , chúng tôi đang cố gắng xây dựng một nền tảng như vậy. Argonaut là một lớp điều phối (trừu tượng) phía trên tài khoản đám mây của bạn. Nói cách khác, nó vận hành tài khoản đám mây của bạn .

• Nó được quản lý hoàn toàn
• Đó là vùng chứa gốc
• Nó có hỗ trợ gốc để làm việc với KaaS hoặc Kubernetes được quản lý như EKS (hỗ trợ GKE sẽ ra mắt trong vài tuần nữa) và FaaS như AWS Lambda (sắp có hỗ trợ Chức năng đám mây).
• Bạn có thể chạy bất kỳ biểu đồ điều khiển nào trên các ứng dụng được triển khai với Argonaut.
• Nó có một hệ sinh thái mở rộng của các tiện ích bổ sung của bên thứ ba, có thể là để theo dõi, ghi nhật ký, tìm kiếm, v.v. Ví dụ bao gồm Datadog , Prometheus , ELK , v.v.

Để kết luận

Khi chuyển sang bất kỳ cách vận hành cơ sở hạ tầng mới nào bằng PaaS hoặc CaaS, nguyên tắc chung là sử dụng tính trừu tượng ở mức cao nhất sẽ giải quyết được vấn đề của bạn mà không đặt ra bất kỳ giới hạn không cần thiết nào đối với khối lượng công việc. Nếu bạn là một ops-noobs hoặc một kỹ sư ứng dụng, chúng tôi khuyên bạn nên làm như sau:

• Bắt đầu với PaaS gốc vùng chứa và từ từ chuyển đổi thành CaaS hoặc KaaS được xác nhận. Điều này giúp bạn bắt đầu nhanh chóng, củng cố kiến ​​thức của bạn, giảm rào cản trong việc áp dụng các công nghệ tối ưu và giúp bạn học các phương pháp hay thông qua các cài đặt mặc định được nhúng.
• Theo thời gian, khi kiến ​​thức chuyên sâu của bạn tăng lên, bạn có thể bắt đầu tìm hiểu các giá trị mặc định hoặc thậm chí sử dụng trực tiếp công nghệ gốc.

Chú thích

1. Giá của Heroku là theo dyno, tức là, các thùng chứa mà Heroku sử dụng để chạy trên EC2 ở phần phụ trợ. Vì Heroku không vận hành ngăn xếp cơ sở hạ tầng bên dưới (trên AWS), bạn phải trả tổng số Heroku cho dynos và AWS cho cơ sở hạ tầng. Đối với Cloud Run, Container Apps hoặc App Runner, bạn chỉ phải trả cho khối lượng công việc mà công việc của bạn thực hiện chứ không phải cho lưu lượng truy cập. Và do đó chúng rẻ hơn nhiều so với Heroku.

Liên kết: https://medium.com/faun/the-top-elastic-beanstalk-alternatives-for-startups-in-2022-f09f2c636260

#devops #aws #kubernetes #aruze 

Лучшие альтернативы Elastic Beanstalk для стартапов в 2022 году

Перед разработчиками стартапов почти всегда стоит вопрос о наиболее экономичном способе получения преимуществ облака без необходимости управлять базовыми системами. Много лет назад, когда мы все еще создавали монолиты и использовали инстансы EC2 , Elastic Beanstalk (или Google App Engine и Azure App Service) был заманчивым выбором для молодых стартапов, стремящихся к быстрому развертыванию.

Даже тогда Elastic Beanstalk (EB) подходил только для некритичных приложений, требующих стандартной конфигурации и развертывания. (Вот несколько рассказов реальных разработчиков , которые обожглись на EB). Кроме того, Elastic Beanstalk уже некоторое время не подвергался серьезному обновлению , поэтому стоит ли вам больше использовать его даже для некритичных приложений? Каковы современные альтернативы Elastic Beanstalk в 2022 году?

Большая часть существующей информации об альтернативах EB либо перечисляет в равной степени устаревшие PaaS от других облачных провайдеров, либо сравнивает их с застойным Heroku. И редко они взвешивают альтернативы с точки зрения стартапов с бережливой командой или вообще без нее. В этом посте предпринята попытка перечислить и сравнить варианты Elastic Beanstalk в 2022 году. Это будет полезно для вас, если:

• Вы — растущий стартап, которому необходимо создавать и масштабировать критически важные приложения — такие аспекты, как время развертывания, задержка и устранение неполадок, имеют для вас жизненно важное значение.
• В настоящее время вы вручную собрали воедино свою инфраструктуру и процессы. И вы оцениваете, какая PaaS больше всего подходит для вас.
• Вы уже используете EB, но хотите отказаться от него, потому что теперь, когда вы масштабируетесь, ограничения EB причиняют вам вред — нестабильные и медленные развертывания и отсутствие прозрачности в отношении сбоев и обновлений, и это лишь некоторые из них.
• Вы хотите, чтобы ваши приложения работали без найма операционной команды или только с командой бережливого управления.

Теперь мы понимаем, что чтение этого поста само по себе не поможет вам сузить выбор PaaS для вашего стартапа, потому что можно принять решение только после рассмотрения нюансов своего варианта использования, набора навыков команды и связанных с этим затрат. Тем не менее, мы надеемся, что этот блог поможет вам ориентироваться в различных технологиях, которые могут помочь вам найти решение для вашего растущего масштаба.

Альтернативы, которые не подходят

Следовательно, в этой статье не признаются следующие практические альтернативы ЭБ:

• Heroku : несмотря на непревзойденный опыт разработчиков, мы не рекомендуем больше начинать с Heroku, потому что он часто намного дороже в масштабе , чем любые другие альтернативы, и он не выпускал никаких заметных обновлений в течение многих лет. Например, он по-прежнему не поддерживает HTTP/2 .
• IaaS : IaaS требует, чтобы вы самостоятельно настраивали свои серверы, задавали сетевые правила, управляли автомасштабированием, обновлениями безопасности и т. д. Хотя этот метод дает вам больше контроля и гибкости, чем PaaS, такой как Elastic Beanstalk, он сопряжен со значительными затратами, связанными с наймом большой специализированной команды по эксплуатации.
• FaaS : Faas подходит для запуска асинхронных заданий и приложений, управляемых событиями, таких как RESTful. И во многих из этих вариантов использования FaaS является побочным продуктом вашего основного приложения, а не основным. Для вариантов использования, удобных для FaaS, это также может быть вашим основным приложением, когда вы только начинаете и сталкиваетесь с непостоянными пиками трафика. Но этот пост посвящен стартапам с гораздо более широкими вариантами использования, чем те, которые подходят для FaaS.

Переходим к альтернативам.

Устаревшая полностью управляемая PaaS в публичных облаках

Существует 2 решения PaaS, по одному от двух ведущих облачных провайдеров: Google и Microsoft, которые почти эквивалентны Elastic Beanstalk:

• Google App Engine
• Служба приложений Azure

Основным преимуществом использования любого предложения PaaS от облачного провайдера, будь то Elastic Beanstalk, App Engine или App Service, является ускорение выхода на рынок за счет устранения накладных расходов на обработку деталей развертывания, выделения ресурсов, балансировки нагрузки, безопасности, масштабирования и мониторинг работоспособности приложений.

Итак, как вы оцениваете их друг против друга?

Сервер приложений Google

Несмотря на то, что он такой же многофункциональный и проверенный в боевых условиях, теперь сама Google считает App Engine устаревшим продуктом . Мы включили его в качестве альтернативы, потому что некоторые из вас могли спросить нас, почему, если мы этого не сделали. Сегодня сама Google рекомендует разработчикам App Engine перейти на более современный Cloud Run — родственный сервис App Engine. (подробнее об этом позже)

Служба приложений Azure

Если ваше приложение использует технологии Майкрософт, такие как .NET, его просто проще запустить в службе приложений, чем в EB или App Engine. Но опять же, подобно Elastic Beanstalk и App Engine, это устаревшая PaaS. Вам лучше оценить более современные предложения PaaS от Microsoft.

Наша рекомендация

Elastic Beanstalk, App Engine и App Service лучше всего подходят для запуска простых веб-приложений или серверных частей мобильных приложений на бессерверной платформе. Это также устаревшие предложения. Хотя они получают регулярные обновления, за последние несколько лет в них было добавлено несколько примечательных функций. Независимо от того, хотите ли вы выбрать свою первую PaaS или альтернативу существующей настройке Elastic Beanstalk, мы настоятельно рекомендуем вам продолжить чтение, чтобы узнать больше о современных полностью управляемых и бессерверных вариантах, которые также рассчитаны на будущее.

Однако, если вы все еще считаете, что одного из этих PaaS достаточно для вашего случая использования, и хотите выбрать один из них, вот что мы должны сказать. Функции или базовая реализация редко будут определять, какую из них вы выберете, потому что вы можете выполнить любой вариант использования с любой из них (с обходными путями или без них). Таким образом, было бы два способа обдумать ваше решение:

• Если вы уже используете AWS Elastic Beanstalk, миграция в другое облако (хотя и не неслыханное) только для их PaaS (App Engine или App Service) вряд ли будет идеальным выбором, если только ваша команда не имеет опыта работы с другим облачным провайдером или нет существенная разница в стоимости использования функций, которые вас интересуют.
• Если вы выбираете свою первую PaaS, проведите анализ рентабельности услуг, которые вы хотите запустить, их взаимодействия и опыта вашей команды с этим конкретным поставщиком облачных услуг.

Примечание. Другие более мелкие облачные провайдеры, такие как DigitalOcean, предлагают аналогичные услуги с, вероятно, гораздо лучшей поддержкой клиентов и по более низкой цене, но широта вариантов использования, с которыми вы можете справиться, ограничена по сравнению с PaaS других облачных провайдеров.

Перейдем к современным альтернативам.

PaaS в частных облаках

Класс недавних предложений PaaS, таких как Fly , Render и Railway , появился, чтобы заполнить пробел, созданный застойным Heroku и все более сложным ландшафтом предложений поставщиков общедоступных облаков.

Fly против Render против Railway

Хотя Render, Fly и Railway часто противопоставляются друг другу при поиске опыта, похожего на Heroku, они не являются почти эквивалентными. Итак, сначала давайте сравним их друг с другом:

• Render гораздо больше похож на Heroku, то есть отполирован в своем опыте разработки и возможностях, таких как документация, информационные панели, интерфейс командной строки и т. д., чем Fly или Railway.
• Render поддерживает гораздо меньше регионов, чем Fly . Информации о регионах, поддерживаемых РЖД, нет.
• Цены на Fly and Render сложны. Приятно, что цены на Railway основаны на использовании с щедрым бесплатным уровнем.
• (На данный момент) И Fly, и Render предоставляют полностью управляемый Postgres. Железная дорога поддерживает интеграцию без настройки с Postgres и несколькими другими базами данных, но ни одна из этих интеграций не является полностью управляемой.
• Нет очередей поддержки Fly, Render или Railway. Таким образом, они не подходят для случаев использования, требующих этих возможностей.
• И Render, и Railway поддерживают монорепозитории; Летать нет.

Наша рекомендация

Если вы уже используете Elastic Beanstalk и рассматриваете возможность миграции для обеспечения гибкости или увеличения масштаба, ни Fly, ни Render, ни Railway вам не подходят. На самом деле, они могут быть более ограничивающими.

Но если вы ищете свою первую PaaS, вам следует знать следующее:

• Fly оптимизирован для периферийных приложений, как никакой другой PaaS, и является главным претендентом, если вы создаете такое приложение.
• (На данный момент) Fly, Render или Railyway отлично подходят для таких случаев использования, как запуск статического веб-сайта, создание простого приложения CRUD или приложения, не требующего базы данных (при условии, что ваша среда выполнения поддерживается).
• Поскольку все они поддерживают образы докеров, ваша блокировка довольно ограничена их проприетарными функциями. Таким образом, блокировка не должна вызывать беспокойства при их оценке.
• Если вы не хотите использовать функции Fly-only, Render and Railway более удобна для разработчиков и может быть более ориентирована на будущее.
• Простое ценообразование на железной дороге дает повод попробовать ее раньше всех.

Контейнерная PaaS в публичных облаках

Контейнерная PaaS — это бессерверная, полностью управляемая служба для развертывания контейнерных приложений и API.

Как и в случае с устаревшей PaaS, вы можете предоставить исходный код или образ контейнера. Они позаботятся о развертывании, обновлении, балансировке нагрузки, масштабировании, безопасности и т. д., поэтому вы можете сосредоточиться на обеспечении ценности для бизнеса.

Но в отличие от устаревших PaaS , они оптимизированы для создания и размещения не только веб-приложений и мобильных приложений, но и API-интерфейсов, микросервисов, длительных процессов, фоновых задач и приложений, управляемых событиями.

Существует три заслуживающих внимания полностью управляемых контейнерных приложения PaaS в общедоступных облаках: Google Cloud Run (общедоступно с ноября 2019 г.), AWS App Runner ( запущено в мае 2021 г.) и Azure Container Apps (общедоступно — май 2022 г.).

Cloud Run, App Runner и контейнерные приложения

• Хотя все они могут развертываться как из образов контейнеров, так и из исходного кода, у каждого из них есть свои ограничения на поддерживаемые типы образов, репозиториев исходного кода и языковых сред выполнения.
• Cloud Run поддерживает больше языков, чем Container Apps и App Runner .
• Приложения Cloud Run и Container поддерживают HTTP/2, WebSockets и gRPC, а App Runner — нет .
• Приложения Cloud Run и Container поддерживают масштабирование до 0, а App Runner — нет .
• Поддержка фоновых заданий не идеальна в App Runner и Cloud Run , но Container Apps утверждает, что поддерживает их.
• Облачный запуск поддерживает синее/зеленое, канареечное и чередующееся развертывание. Приложения-контейнеры поддерживают только сине-зеленые и канареечные развертывания. Но App runner не поддерживает ни один из них.
• Приложения-контейнеры поддерживают несколько контейнеров в одной службе, а Cloud Run и App Runner — нет.
• Блокировка
• Практически нет привязки к Cloud Run: он основан на KNative с открытым исходным кодом. Cloud Run — это всего лишь слой поверх KNative с открытым исходным кодом. Таким образом, вы можете развернуть свой контейнер в любом кластере K8S, используя определения KNative.
• Приложение-контейнер: ваши единственные вложения — это создание образа контейнера, а затем запуск нескольких команд для его развертывания. Кроме того, он работает на Kubernetes с открытым исходным кодом. Поэтому, если вы решите мигрировать, вы сможете сделать это относительно легко.
• App Runner: он работает на ECS Fargate, собственном предложении AWS, но ваши инвестиции ограничиваются предоставлением образа контейнера, в то время как он позаботится обо всем остальном (будучи PaaS). Таким образом, если вы решите мигрировать, потери невелики.
• Автомасштабирование в Cloud Run работает «из коробки» — без необходимости указывать какое-либо правило — на основе его поведения по умолчанию, когда создается реплика для каждых 100 одновременных запросов. Но и App Runner, и приложения-контейнеры требуют, чтобы вы указали правила автоматического масштабирования.

Наша рекомендация

• Каждый App Runner, Container Apps, Cloud Run, Fly и Render являются относительно новыми PaaS и, следовательно, не прошли боевые испытания.
• Несмотря на то, что все они являются относительно новыми, Fly и Render неизбежно будут иметь более ограниченные возможности, чем их аналоги в общедоступном облаке на основе контейнеров, потому что у общедоступных облаков есть обширный набор предложений, которые вы можете использовать для решения практически любого варианта использования. Возможно, это не очень удобный способ решить эту проблему, но он не заблокирует вас. Наоборот, как только вы упираетесь в их возможности с помощью Fly или Render, вы должны отказаться от них.
• Если вы ищете свою первую PaaS, все они должны быть оценены с точки зрения вашего варианта использования и навыков команды.
• Однако, если вы хотите отказаться от Elastic Beanstalk для большей гибкости при масштабировании, оцените App Runner и CaaS от AWS (подробнее об этом позже) .

Контейнеры как услуга (CaaS) в публичных облаках

Все вышеперечисленные варианты PaaS позволяют разрабатывать и развертывать приложения без необходимости создавать, управлять и поддерживать инфраструктуру. Контейнерно-ориентированная PaaS почти такая же, как CaaS, за исключением того, что в некоторых случаях, как мы увидим, CaaS предлагает больше контроля.

Эта абстракция контейнерной PaaS прекрасно работает в начале для большинства стартапов, но если в какой-то момент вам потребуется больше контроля, вам нужно будет оценить единственное другое заметное предложение CaaS: ECS. Давайте взглянем на некоторые из его заметных плюсов и минусов:

AWS ECS (с Fargate или без него)

• Требуется собрать десятки деталей, прежде чем вы сможете что-либо развернуть на нем. Итак, пользовательский опыт неприятный.
• Настройка автомасштабирования на ECS сложна (как и весь остальной опыт его использования).
• Является полностью проприетарным и заставляет вас полностью полагаться на AWS; количество ресурсов, которые необходимо создать, и формат написания определений приложений гарантируют, что мы привязаны к AWS. Вам будет чрезвычайно трудно съехать, если вы выберете это. Но опять же, блокировка должна быть оценена по сравнению с тем, что она облегчает для вас.
• Его частный характер также привел к отсутствию поддержки сообщества.

Примечание. Мы не включили Azure Container Instances (ACI) в качестве альтернативы, поскольку она не поддерживает горизонтальное автоматическое масштабирование. Вертикальное масштабирование также чисто ручное. Все, что вы можете сделать, это запустить отдельные экземпляры, которые изолированы друг от друга. Следовательно, ACI нельзя использовать в производстве для любого приложения, если только в вашем случае недостаточно одного экземпляра приложения.

Наша рекомендация

• Независимо от вашего варианта использования, вообще пропустите ACI.
• Если вы уже используете AWS и ваш вариант использования не подходит для Kubernetes, сравните ECS с App Runner для запуска управляемых контейнеров.
• ECS обеспечивает большую гибкость по сравнению с App Runner за счет дополнительной административной работы с вашей стороны. Например, он может запускать несколько контейнеров в одной службе, а App Runner — нет.
• Недостаточный опыт разработчиков ECS требует значительного времени на настройку. Вы должны быть морально готовы к этому.
• Если ваша цель состоит в том, чтобы не нанимать сотрудников, ECS не рекомендуется.
• Если AWS не является ограничением, Cloud Run наиболее удобен для разработчиков для развертывания контейнерных приложений. Он поставляется с наименьшими блокировками и является наиболее удобным способом запуска бессерверных и управляемых контейнеров. Мы настоятельно рекомендуем вам оценить его.

Kubernetes как услуга (KaaS) или управляемый Kubernetes

Логически CaaS будет следующим шагом, если кто-то захочет перейти от PaaS для обеспечения гибкости и масштабируемости. Но некоторые варианты использования также требуют рассмотрения Kubernetes. KaaS или управляемые службы Kubernetes, такие как GKE , EKS и AKS , абстрагируются от управления плоскостью управления и, следовательно, с ними проще работать, чем напрямую с Kubernetes.

Но что вы должны знать об этом, чтобы принять более взвешенное решение?

• Kubernetes — это система оркестрации контейнеров с открытым исходным кодом. CaaS, как и ECS, имеет проприетарную систему оркестровки контейнеров — их главный недостаток по сравнению с Kubernetes. (Хотя приложения Cloud Run и Azure Container Apps не страдают от этого, поскольку их поддерживает Kubernetes).
• Самое замечательное в KaaS то, что это Kubernetes — с открытым исходным кодом, значительной поддержкой сообщества и растущей экосистемой инструментов для решения распространенных вариантов использования — поэтому существует минимальная блокировка и бесконечная масштабируемость.
• Хотя KaaS упростила управление плоскостью управления, она по-прежнему оставляет за вами администрирование рабочих узлов, таких как обновления и сеть. Для таких огромных накладных расходов требуется специальная команда со специальными знаниями Kubernetes.

Наша рекомендация

• Оцените, требуется ли Kubernetes для вашего варианта использования, или вам подойдут контейнеры (через встроенные в контейнеры PaaS или CaaS).
• Если вы решите продолжить работу с Kubernetes, оцените, есть ли у вас команда для работы с KaaS, такой как GKE, EKS и AKS.
• В общем, GKE — самая зрелая KaaS на сегодняшний день, которую мы рекомендуем.

Если у вас нет времени и ресурсов, чтобы отказаться от KaaS сегодня, но вы решили пойти по пути Kubernetes, может быть золотая середина между KaaS, CaaS и PaaS.

Золотая середина между PaaS, CaaS и KaaS

Золотая середина между PaaS, CaaS и Kaas будет использовать лучшие характеристики каждого из них и не будет иметь соответствующих ограничений.

• В отличие от KaaS или CaaS, и именно как PaaS — он будет полностью управляемым и бессерверным.
• В отличие от проприетарных CaaS или PaaS, он основан на инструменте с открытым исходным кодом, таком как Kubernetes.
• Это не привязывает вас к конкретному облачному провайдеру или его инструментам.
• Это дает вам возможность интегрироваться и использовать обширную экосистему сторонних инструментов для ведения журналов, мониторинга, хранения и т. д.

В Argonaut мы пытаемся построить такую ​​платформу. Argonaut — это слой оркестровки (абстракции) над вашей облачной учетной записью. Другими словами, он управляет вашей облачной учетной записью.

• Он полностью управляем
• Это нативный контейнер
• Он имеет встроенную поддержку работы с KaaS или управляемым Kubernetes, например EKS (поддержка GKE появится через несколько недель), и FaaS, например AWS Lambda (скоро появится поддержка облачных функций).
• Вы можете запустить любую диаграмму управления для приложений, развернутых с помощью Argonaut.
• Он имеет расширяющуюся экосистему сторонних надстроек, будь то мониторинг, ведение журнала, поиск и т. д. Примеры включают Datadog , Prometheus , ELK и т. д.

Заключить

При переходе на любой новый способ эксплуатации инфраструктуры с использованием PaaS или CaaS рекомендуется использовать абстракцию самого высокого уровня, которая решит вашу проблему, не накладывая ненужных ограничений на рабочую нагрузку. Если вы новичок в эксплуатации или разработчик приложений, мы рекомендуем следующее:

• Начните с контейнерной PaaS и постепенно переходите к самоуверенной CaaS или KaaS. Это поможет вам быстро приступить к работе, улучшит ваши знания, уменьшит барьер для внедрения оптимальных технологий и поможет вам изучить передовой опыт с помощью встроенных настроек по умолчанию.
• Со временем, по мере увеличения глубины ваших знаний, вы сможете начать возиться со значениями по умолчанию или даже напрямую использовать нативную технологию.

Сноски

1. Стоимость Heroku указана за dyno, т. е. контейнеры, которые Heroku использует для работы поверх EC2 на серверной части. Поскольку Heroku не управляет базовым инфраструктурным стеком (на AWS), вы платите в общей сложности Heroku за dynos и AWS за инфраструктуру. В отличие от Cloud Run, Container Apps или App Runner, вы платите только за рабочую нагрузку, которую выполняет ваше задание, а не за трафик. И, следовательно, они выходят намного дешевле, чем Heroku.

Ссылка: https://medium.com/faun/the-top-elastic-beanstalk-alternatives-for-startups-in-2022-f09f2c636260

#devops #aws #kubernetes #aruze 

Meilleures Alternatives Elastic Beanstalk Pour Les Startups En 2022

Les développeurs des startups sont presque toujours confrontés à la question de la manière la plus rentable d'obtenir les avantages du cloud sans avoir à gérer les systèmes sous-jacents. Il y a des années, lorsque nous construisions encore des monolithes et utilisions des instances EC2 , Elastic Beanstalk (ou Google App Engine et Azure App Service) était un choix tentant pour les jeunes startups cherchant à se déployer rapidement.

Même alors, Elastic Beanstalk (EB) ne convenait qu'aux applications non critiques qui nécessitaient une configuration et des déploiements standard. (Voici quelques témoignages de vrais développeurs qui se brûlent les mains avec EB). En outre, Elastic Beanstalk n'a pas connu de mise à jour majeure depuis un certain temps , alors devriez-vous l'utiliser même pour des applications non critiques ? Quelles sont les alternatives modernes à Elastic Beanstalk en 2022 ?

Une grande partie des informations existantes sur les alternatives d'EB répertorie également les PaaS hérités d'autres fournisseurs de cloud ou se comparent à Heroku, qui stagne. Et ils évaluent rarement les alternatives du point de vue des startups avec une équipe maigre ou pas d'équipe opérationnelle du tout. Cet article tente de répertorier et de comparer les options d'Elastic Beanstalk en 2022. Il vous sera utile si :

• Vous êtes une startup en pleine croissance qui a besoin de créer et de mettre à l'échelle des applications critiques. Des aspects tels que le temps de déploiement, la latence et le dépannage sont vitaux pour vous.
• Vous avez actuellement assemblé manuellement votre infrastructure et vos processus. Et vous évaluez quel PaaS vous convient le mieux.
• Vous utilisez déjà EB, mais vous souhaitez en migrer car maintenant, à mesure que vous évoluez, les limites d'EB vous nuisent : déploiements instables et lents et manque de transparence concernant les échecs et les mises à jour, pour n'en nommer que quelques-uns.
• Vous souhaitez que vos applications fonctionnent sans embaucher une équipe d'exploitation ou avec seulement une équipe d'exploitation allégée.

Maintenant, nous réalisons que la lecture de cet article ne vous aidera pas à affiner le PaaS pour votre startup - car on ne peut décider qu'après avoir pris en compte les nuances de son cas d'utilisation, les compétences de l'équipe et les coûts associés. Cependant, nous espérons que ce blog vous aidera à naviguer à travers les différentes technologies qui peuvent vous aider à résoudre votre problème en pleine croissance.

Des alternatives qui ne font pas la coupe

Par conséquent, cet article ne reconnaît pas les éléments suivants comme des alternatives pratiques à l'EB :

• Heroku : Malgré son expérience de développeur inégalée, nous ne recommandons plus de démarrer sur Heroku car il est souvent beaucoup plus cher à grande échelle que toute autre alternative, et il n'a pas publié de mises à jour notables depuis de nombreuses années. Par exemple, il ne prend toujours pas en charge HTTP/2 .
• IaaS : IaaS vous oblige à configurer vous-même vos serveurs, à spécifier des règles de mise en réseau, à gérer l'autoscaling, les mises à jour de sécurité, etc. Bien que cette méthode vous donne plus de contrôle et de flexibilité qu'un PaaS comme Elastic Beanstalk, cela a un coût considérable d'embaucher une grande équipe d'opérations spécialisées.
• FaaS : Faas convient à l'exécution de tâches asynchrones et d'applications événementielles telles que RESTful. Et dans bon nombre de ces cas d'utilisation, le FaaS est un spin-off de votre application principale, et non celle de base. Pour les cas d'utilisation compatibles FaaS, il peut également s'agir de votre application principale lorsque vous démarrez et que vous rencontrez des pics de trafic incohérents. Mais cet article s'adresse aux startups avec des cas d'utilisation beaucoup plus larges que ceux adaptés au FaaS.

Passons aux alternatives.

PaaS entièrement géré sur les clouds publics

Il existe 2 solutions PaaS, chacune proposée par les deux principaux fournisseurs de cloud : Google et Microsoft, qui sont presque équivalentes à Elastic Beanstalk :

• App Engine de Google
• Service d'application d'Azure

Le principal avantage de l'utilisation de l'offre PaaS de n'importe quel fournisseur de cloud, qu'il s'agisse d'Elastic Beanstalk, d'App Engine ou d'App Service, est un délai de mise sur le marché plus rapide en éliminant les frais généraux liés à la gestion des détails de déploiement, de provisionnement de capacité, d'équilibrage de charge, de sécurité, de mise à l'échelle et surveillance de la santé des applications.

Alors, comment les évaluez-vous les uns par rapport aux autres ?

Google App Engine

Bien qu'il soit aussi riche en fonctionnalités et testé au combat, Google lui-même considère maintenant App Engine comme un produit hérité . Nous l'avons inclus comme alternative parce que certains d'entre vous nous ont peut-être demandé pourquoi si nous ne l'avions pas fait. Aujourd'hui, Google lui-même recommande aux développeurs d'App Engine de passer au Cloud Run plus moderne , le service frère d'App Engine. (Plus d'informations plus tard)

Service d'applications Azure

Si votre application utilise des technologies Microsoft telles que .NET, il est simplement plus facile d'exécuter votre application sur App Service que sur EB ou App Engine. Mais encore une fois, comme Elastic Beanstalk et App Engine, il s'agit d'un PaaS hérité. Vous feriez mieux d'évaluer les offres PaaS plus modernes de Microsoft.

Notre recommandation

Elastic Beanstalk, App Engine et App Service sont tous les mieux adaptés pour exécuter des applications Web simples ou des backends d'applications mobiles sur une plate-forme sans serveur. Ce sont également des offres héritées. Bien qu'ils reçoivent des mises à jour régulières, peu de fonctionnalités notables leur ont été ajoutées au cours des dernières années. Que vous cherchiez à choisir votre premier PaaS ou une alternative à une configuration Elastic Beanstalk existante, nous vous recommandons fortement de continuer à lire pour en savoir plus sur les options modernes entièrement gérées et sans serveur qui sont également évolutives.

Cependant, si vous pensez toujours qu'un de ces PaaS est juste suffisant pour votre cas d'utilisation et que vous souhaitez en choisir un, voici ce que nous avons à dire. Les fonctionnalités ou l'implémentation sous-jacente décideront rarement de celle que vous choisirez, car vous pouvez accomplir n'importe quel cas d'utilisation avec n'importe laquelle d'entre elles (avec ou sans solutions de contournement). Il y aurait donc deux façons de penser à votre décision :

• Si vous utilisez déjà Elastic Beanstalk d'AWS, migrer vers un autre cloud (mais pas inconnu) uniquement pour leur PaaS (App Engine ou App Service) serait rarement un choix idéal, à moins que l'expertise de votre équipe ne soit maintenant avec un autre fournisseur de cloud, ou qu'il n'y ait une différence de coût significative dans l'utilisation des fonctionnalités qui vous intéressent.
• Si vous choisissez votre premier PaaS, effectuez une analyse coûts-avantages des services que vous souhaitez exécuter, de la manière dont ils interagiront et de l'expérience de votre équipe avec ce fournisseur de cloud spécifique.

Remarque : d'autres petits fournisseurs de cloud comme DigitalOcean offrent des services similaires avec un support client probablement bien meilleur et à moindre coût, mais l'étendue des cas d'utilisation que vous pouvez gérer avec eux est limitée par rapport au PaaS d'autres fournisseurs de cloud.

Passons aux alternatives modernes .

PaaS sur Cloud Privé

Une classe d'offres PaaS récentes telles que Fly , Render et Railway a vu le jour pour combler le vide créé par un Heroku stagnant et le paysage de plus en plus complexe des offres des fournisseurs de cloud public.

Fly vs Render vs Railway

Bien que Render, Fly et Railway soient souvent opposés lors de la recherche d'une expérience de type Heroku, ils ne sont pas presque équivalents. Alors d'abord, comparons-les entre eux:

• Le rendu est beaucoup plus semblable à Heroku, c'est-à-dire raffiné dans son expérience de développeur et ses capacités telles que la documentation, les tableaux de bord, la CLI, etc., que Fly ou Railway.
• Render prend en charge beaucoup moins de régions que Fly . Il n'y a aucune information sur les régions prises en charge par Railway.
• La tarification de Fly and Render est complexe. Agréablement, la tarification de Railway est basée sur l'utilisation avec un niveau gratuit généreux.
• (À partir de maintenant) Fly et Render fournissent Postgres entièrement géré. Railway prend en charge l'intégration sans configuration avec Postgres et quelques autres bases de données, mais aucune de ces intégrations n'est entièrement gérée.
• Aucune des files d'attente de support Fly, Render ou Railway. Ils ne conviennent donc pas aux cas d'utilisation nécessitant ces fonctionnalités.
• Render et Railway prennent en charge Monorepos ; Fly ne le fait pas.

Notre recommandation

Si vous utilisez déjà Elastic Beanstalk et que vous envisagez de migrer pour plus de flexibilité ou pour gérer plus d'échelle, aucun de Fly, Render ou Railway ne vous convient. En fait, ils pourraient être plus limitatifs.

Mais si vous cherchez votre premier PaaS, vous devez savoir ce qui suit :

• Fly est optimisé pour les applications Edge comme aucun autre PaaS et est un concurrent de premier plan si vous créez une telle application.
• (Pour l'instant) Fly, Render ou Railyway conviennent parfaitement à des cas d'utilisation tels que l'exécution d'un site Web statique, la création d'une application CRUD simple ou une application qui ne nécessite pas de base de données (en supposant que votre environnement d'exécution est pris en charge).
• Comme ils prennent tous en charge les images Docker, votre verrouillage est assez limité à leurs fonctionnalités propriétaires. Ainsi, le verrouillage ne devrait pas être une préoccupation lors de leur évaluation.
• À moins que vous ne cherchiez à utiliser les fonctionnalités Fly uniquement, Render and Railway est plus convivial pour les développeurs et pourrait être plus évolutif.
• La tarification simple de Railway justifie de l'essayer avant tout le monde.

PaaS natif de conteneur sur les clouds publics

Le PaaS natif de conteneur est un service sans serveur entièrement géré pour déployer des applications et des API conteneurisées.

Comme pour l'ancien PaaS, vous pouvez fournir le code source ou une image de conteneur. Ils s'occupent du déploiement, des mises à niveau, de l'équilibrage de charge, de la mise à l'échelle, de la sécurité, etc., afin que vous puissiez vous concentrer sur la création de valeur commerciale.

Mais contrairement aux PaaS hérités , ils sont optimisés pour créer et héberger non seulement des applications Web et mobiles, mais également des API, des microservices, des processus de longue durée, des tâches en arrière-plan et des applications pilotées par des événements.

Il existe trois PaaS entièrement gérés natifs de conteneurs remarquables sur les clouds publics : Google Cloud Run (généralement disponible à partir de novembre 2019), AWS App Runner ( lancé en mai 2021 ) et Azure Container Apps (généralement disponible — mai 2022).

Cloud Run contre App Runner contre applications de conteneur

• Bien qu'ils puissent tous être déployés à partir d'images de conteneur et de code source, ils ont chacun des contraintes différentes sur le type d'images, les référentiels de code source et les runtimes de langage pris en charge.
• Cloud Run prend en charge plus de langues que Container Apps et App Runner .
• Cloud Run et les applications de conteneur sont compatibles avec HTTP/2, WebSockets et gRPC, mais pas App Runner .
• Cloud Run et Container Apps prennent en charge la mise à l'échelle jusqu'à 0, contrairement à App Runner .
• La prise en charge des tâches en arrière-plan n'est pas idéale dans App Runner et Cloud Run , mais Container Apps prétend les prendre en charge.
• Cloud Run prend en charge les déploiements bleu/vert, Canary et progressifs. Les applications de conteneur ne prennent en charge que les déploiements bleu/vert et Canary . Mais App Runner ne prend en charge aucun de ces éléments.
• Les applications de conteneur prennent en charge plusieurs conteneurs dans un seul service, contrairement à Cloud Run et App Runner.
• Verrouillage
• Pratiquement aucun verrouillage Cloud Run : il est basé sur KNative, qui est open source. Cloud Run n'est qu'une couche au-dessus de KNative, qui est open source. Ainsi, vous pouvez déployer votre conteneur dans n'importe quel cluster K8S à l'aide de définitions KNative.
• Application conteneur : votre seul investissement consiste à créer l'image du conteneur, puis à exécuter quelques commandes pour la déployer. De plus, il est alimenté par Kubernetes, qui est open source. Donc, si vous choisissez de migrer, vous pourrez le faire relativement facilement.
• App Runner : il fonctionne sur ECS Fargate, qui est une offre AWS propriétaire, mais votre investissement se limite à fournir l'image du conteneur pendant qu'il s'occupe du reste (étant un PaaS). Il y a donc peu d'efforts perdus si vous choisissez de migrer.
• L'autoscaling dans Cloud Run est prêt à l'emploi, sans que vous ayez à spécifier de règle, en fonction de son comportement par défaut consistant à créer une instance dupliquée toutes les 100 requêtes simultanées. Cependant, App Runner et Container Apps vous obligent à spécifier des règles de mise à l'échelle automatique.

Notre recommandation

• Chaque App Runner, Container Apps, Cloud Run, Fly et Render sont des PaaS relativement nouveaux et n'ont donc pas été testés au combat.
• Bien qu'ils soient tous relativement nouveaux, Fly et Render seront inévitablement plus restrictifs que leurs homologues de cloud public natifs de conteneurs, car les clouds publics disposent d'un ensemble complet d'offres que vous pouvez utiliser pour résoudre à peu près n'importe quel cas d'utilisation. Ce n'est peut-être pas une bonne façon de le résoudre, mais cela ne vous bloquera pas. Au contraire, une fois que vous avez atteint un mur avec leurs capacités avec Fly ou Render, vous devez migrer hors d'eux.
• Si vous recherchez votre premier PaaS, ils doivent tous être évalués en fonction de votre cas d'utilisation et des compétences de votre équipe.
• Cependant, si vous cherchez à migrer d'Elastic Beanstalk pour plus de flexibilité à grande échelle, évaluez App Runner et le CaaS d'AWS (plus à ce sujet plus tard) .

Conteneurs en tant que service (CaaS) sur les clouds publics

Toutes les options PaaS ci-dessus vous permettent de développer et de déployer des applications sans avoir à créer, gérer et entretenir une infrastructure. Le PaaS natif de conteneur est presque identique au CaaS, sauf que dans certains cas, comme nous le verrons, le CaaS offre plus de contrôle.

Cette abstraction du PaaS natif de conteneur fonctionne parfaitement au début pour la plupart des startups, mais si à un moment donné vous avez besoin de plus de contrôle, vous devrez évaluer la seule autre offre CaaS notable : ECS. Jetons un coup d'œil à certains de ses avantages et inconvénients notables :

AWS ECS (avec ou sans Fargate)

• Nécessite l'assemblage de dizaines de pièces avant de pouvoir déployer quoi que ce soit dessus. Ainsi, l'expérience utilisateur est désagréable.
• La configuration de la mise à l'échelle automatique sur ECS est compliquée (comme le reste de l'expérience d'utilisation).
• Est entièrement propriétaire et vous oblige à vous fier entièrement à AWS ; le nombre de ressources que vous devez créer et le format d'écriture des définitions d'application garantissent que nous sommes enfermés dans AWS. Il vous sera extrêmement difficile de déménager si vous le choisissez. Mais encore une fois, le verrouillage doit être évalué par rapport à ce qu'il vous facilite.
• Sa nature exclusive a également conduit à son manque de soutien communautaire.

Remarque : Nous n'avons pas inclus Azure Container Instances (ACI) comme alternative, car il ne prend pas en charge la mise à l'échelle automatique horizontale. La mise à l'échelle verticale est également purement manuelle. Tout ce que vous pouvez faire est d'exécuter des instances uniques isolées les unes des autres. Par conséquent, ACI ne peut être utilisé en production pour aucune application à moins qu'une seule instance de l'application soit suffisante dans votre cas d'utilisation.

Notre recommandation

• Quel que soit votre cas d'utilisation, ignorez complètement ACI.
• Si vous êtes déjà sur AWS et que votre cas d'utilisation n'est pas adapté à Kubernetes, évaluez ECS par rapport à App Runner pour l'exécution de conteneurs gérés.
• ECS offre plus de flexibilité par rapport à App Runner au prix de plus de travail administratif de votre part. Par exemple, il peut exécuter plusieurs conteneurs dans un seul service alors que App Runner ne le peut pas.
• L'expérience de développeur médiocre d'ECS nécessite un temps de configuration important. Vous devez être préparé mentalement à cela.
• Si votre objectif est d'embaucher zéro ops, ECS n'est pas recommandé.
• Si AWS n'est pas une contrainte, Cloud Run est le plus convivial pour les développeurs pour le déploiement d'applications conteneurisées. Il est livré avec le moins de verrouillage et constitue le moyen le plus pratique d'exécuter des conteneurs sans serveur et gérés. Nous vous recommandons vivement de l'évaluer.

Kubernetes en tant que service (KaaS) ou Kubernetes géré

Logiquement, CaaS serait la prochaine étape si l'on voulait migrer hors d'un PaaS pour plus de flexibilité et d'évolutivité. Mais certains cas d'utilisation justifient également la prise en compte de Kubernetes. KaaS ou Managed Kubernetes Services, tels que GKE , EKS et AKS , suppriment la gestion du plan de contrôle et sont donc plus faciles à utiliser que d'utiliser Kubernetes directement.

Mais que devez-vous savoir à ce sujet pour pouvoir prendre une décision plus éclairée ?

• Kubernetes est un système d'orchestration de conteneurs open source. CaaS, comme ECS, dispose d'un système d'orchestration de conteneurs propriétaire - leur principal inconvénient par rapport à Kubernetes. (Cependant, Cloud Run et Azure Container Apps n'en souffrent pas car Kubernetes les alimente)
• La grande chose à propos de KaaS est qu'il s'agit de Kubernetes - qui est open source, bénéficie d'un soutien communautaire considérable et d'un écosystème croissant d'outils pour résoudre les cas d'utilisation courants - il y a donc un verrouillage minimal et une évolutivité infinie.
• Bien que KaaS simplifie la gestion du plan de contrôle, il vous laisse toujours l'administration des nœuds de travail, tels que les mises à niveau et la mise en réseau. Ces énormes frais généraux nécessitent une équipe dédiée avec des connaissances spécialisées sur Kubernetes.

Notre recommandation

• Évaluez si Kubernetes est requis pour votre cas d'utilisation ou si les conteneurs fonctionnent parfaitement pour vous (via PaaS ou CaaS natif de conteneur).
• Si vous décidez d'aller de l'avant avec Kubernetes, évaluez si vous avez l'équipe pour exploiter KaaS comme GKE, EKS et AKS.
• En général, GKE est le KaaS le plus mature à ce jour, et c'est aussi ce que nous recommandons.

Si vous n'avez pas le temps et les ressources à consacrer à KaaS aujourd'hui, mais que vous décidez de suivre la voie Kubernetes, il existe peut-être un juste milieu entre KaaS, CaaS et PaaS.

Un juste milieu entre PaaS, CaaS et KaaS

Un terrain d'entente entre PaaS, CaaS et Kaas reprendrait les meilleures caractéristiques de chacun d'eux et n'aurait pas leurs limites respectives.

• Contrairement à KaaS ou CaaS, et précisément comme PaaS, il sera entièrement géré et sans serveur.
• Contrairement au CaaS ou au PaaS propriétaire, il est basé sur un outil open source tel que Kubernetes.
• Cela ne vous lie pas à un fournisseur de cloud spécifique ou à ses outils.
• Cela vous donne la possibilité d'intégrer et de tirer parti du vaste écosystème d'outils tiers pour la journalisation, la surveillance, le stockage, etc.

Chez Argonaut , nous essayons de construire une telle plateforme. Argonaut est une couche d'orchestration (abstraction) au-dessus de votre compte cloud. En d'autres termes, il gère votre compte cloud.

• C'est entièrement géré
• C'est natif du conteneur
• Il dispose d'une prise en charge native pour travailler avec KaaS ou Kubernetes gérés comme EKS (prise en charge de GKE à venir dans quelques semaines) et FaaS comme AWS Lambda (prise en charge de Cloud Functions à venir).
• Vous pouvez exécuter n'importe quel diagramme de barre sur les applications déployées avec Argonaut.
• Il dispose d'un écosystème en expansion de modules complémentaires tiers, que ce soit pour la surveillance, la journalisation, la recherche, etc. Les exemples incluent Datadog , Prometheus , ELK , etc.

De conclure

Lorsque vous passez à une nouvelle façon d'exploiter l'infrastructure à l'aide d'un PaaS ou d'un CaaS, une bonne règle d'or consiste à utiliser le niveau d'abstraction le plus élevé qui résoudra votre problème sans imposer de limitations inutiles à la charge de travail. Si vous êtes un ops-noobs ou un ingénieur d'application, nous vous recommandons ce qui suit :

• Commencez avec un PaaS natif de conteneur et passez lentement à un CaaS ou KaaS opiniâtre. Cela vous aide à démarrer rapidement, à amorcer vos connaissances, à réduire les obstacles à l'adoption de technologies optimales et à apprendre les bonnes pratiques grâce aux valeurs par défaut intégrées.
• Au fil du temps, à mesure que vos connaissances augmentent, vous pouvez commencer à jouer avec les paramètres par défaut ou même utiliser directement la technologie native.

Notes de bas de page

1. La tarification d'Heroku est par dyno, c'est-à-dire les conteneurs qu'Heroku utilise pour s'exécuter sur EC2 au niveau du backend. Étant donné que Heroku n'exploite pas la pile d'infrastructure sous-jacente (sur AWS), vous payez un total de Heroku pour les dynos et AWS pour l'infrastructure. Contrairement à Cloud Run, Container Apps ou App Runner, vous ne payez que pour la charge de travail exécutée par votre tâche et non pour le trafic. Et par conséquent, ils sont beaucoup moins chers que Heroku.

Lien : https://medium.com/faun/the-top-elastic-beanstalk-alternatives-for-startups-in-2022-f09f2c636260

#devops #aws #kubernetes #aruze 

2022 年最適合初創公司的 Elastic Beanstalk 替代品

初創公司的開發人員幾乎總是面臨著如何以最經濟有效的方式獲得云優勢而無需管理底層系統的問題。多年前，當我們還在構建單體應用程序並使用EC2實例時，Elastic Beanstalk（或 Google App Engine 和 Azure App Service）對於希望快速部署的年輕初創公司來說是一個誘人的選擇。

即使在那時，Elastic Beanstalk (EB) 也只適合需要標準配置和部署的非任務關鍵型應用程序。（這裡有一些真實的開發人員被 EB 燙傷的故事）。此外，Elastic Beanstalk 已經有一段時間沒有進行重大升級了，那麼您是否應該再將它用於非任務關鍵型應用程序？2022 年 Elastic Beanstalk 的現代替代品有哪些？

關於 EB 替代方案的大部分現有信息要么列出來自其他雲提供商的同樣遺留的 PaaS，要么與停滯不前的 Heroku 進行比較。他們很少從擁有精簡或根本沒有運營團隊的初創公司的角度來權衡替代方案。這篇文章試圖列出並比較 2022 年 Elastic Beanstalk 的選項。如果出現以下情況，將對您有所幫助：

• 您是一家成長中的初創公司，需要構建和擴展關鍵應用程序——部署時間、延遲和故障排除等方面對您來說至關重要。
• 您目前已手動將基礎架構和流程拼湊在一起。您正在評估哪種 PaaS 最適合您。
• 您已經在使用 EB，但希望從中遷移出來，因為現在，隨著您的擴展，EB 的限制正在傷害您——不穩定和緩慢的部署以及在故障和更新方面缺乏透明度等等。
• 您希望在不僱傭運維團隊或僅依靠精益運維團隊的情況下運行您的應用程序。

現在，我們意識到，僅閱讀這篇文章並不能幫助您縮小創業公司的 PaaS 範圍——因為只有在考慮了用例的細微差別、團隊的技能以及相關成本之後才能做出決定。但是，我們希望此博客能夠幫助您瀏覽各種可幫助您解決不斷增長的規模的技術。

不合格的替代品

因此，本文不認為以下是實用的 EB 替代方案：

• Heroku：儘管它擁有無與倫比的開發經驗，但我們不建議再開始使用 Heroku，因為它的規模通常比任何其他替代品都要貴得多，而且多年來它沒有發布任何顯著的升級。例如，它仍然不支持 HTTP/2。
• IaaS：IaaS 要求您自行配置服務器、指定網絡規則、管理自動縮放、安全更新等。雖然這種方法比 Elastic Beanstalk 之類的 PaaS 為您提供了更多的控制力和靈活性，但它需要花費大量成本來聘請大型專業運營團隊。
• FaaS：FaaS 適合運行異步作業和事件驅動的應用程序，如 RESTful。在許多這些用例中，FaaS 是核心應用程序的衍生產品，而不是核心應用程序。對於 FaaS 友好的用例，它也可能是您剛開始並獲得不一致的流量峰值時的核心應用程序。但是這篇文章針對的初創公司的用例比適合 FaaS 的用例要廣泛得多。

轉向替代品。

公共雲上的傳統全託管 PaaS

有 2 種 PaaS 解決方案，其他兩大雲提供商各自提供：Google 和 Microsoft，它們幾乎等同於 Elastic Beanstalk：

• 谷歌的應用引擎
• Azure 的應用服務

使用任何云提供商的 PaaS 產品（無論是 Elastic Beanstalk、App Engine 還是 App Service）的主要好處是通過消除處理部署、容量配置、負載平衡、安全性、擴展和應用程序健康監控。

那麼，您如何評價它們之間的對比呢？

谷歌應用引擎

雖然它功能豐富且經過實戰考驗，但現在 Google 自己認為App Engine 是一個遺留產品。我們將它作為替代方案包括在內，因為你們中的一些人可能會問我們為什麼不這樣做。今天，谷歌自己建議 App Engine 開發人員遷移到更現代的Cloud Run ——App Engine 的姊妹服務。（稍後會詳細介紹）

Azure 應用服務

如果您的應用程序使用 Microsoft 技術（例如 .NET），那麼在 App Service 上運行您的應用程序要比在 EB 或 App Engine 上更容易。但同樣，與 Elastic Beanstalk 和 App Engine 類似，它是一種傳統的 PaaS。您最好評估 Microsoft 更現代的 PaaS 產品。

我們的建議

Elastic Beanstalk、App Engine 和 App Service 都最適合在無服務器平台中運行簡單的 Web 應用程序或移動應用程序後端。這些也是遺留產品。雖然它們會定期更新，但在過去幾年中幾乎沒有添加值得注意的功能。無論您是希望選擇您的第一個 PaaS 還是現有 Elastic Beanstalk 設置的替代方案，我們強烈建議您繼續閱讀以了解有關完全託管和無服務器的現代選項的更多信息，這些選項也是面向未來的。

但是，如果您仍然認為這些 PaaS 中的一種足以滿足您的用例，並且想要選擇其中一種，那麼這就是我們要說的。特性或底層實現很少會決定你選擇哪一個，因為你可以用它們中的任何一個來完成任何用例（有或沒有變通方法）。因此，將有兩種方式來考慮您的決定：

• 如果您已經在使用 AWS 的 Elastic Beanstalk，那麼僅僅為了他們的 PaaS（App Engine 或 App Service）遷移到另一個雲（儘管並非聞所未聞）很少是理想的選擇，除非您的團隊的專業知識現在與另一個雲提供商合作，或者有使用您感興趣的功能的顯著成本差異。
• 如果您正在選擇您的第一個 PaaS，請對您想要運行的服務、它們將如何交互以及您的團隊與該特定雲提供商的經驗進行成本效益分析。

注意：其他較小的雲提供商（如 DigitalOcean）提供類似的服務，可能提供更好的客戶支持和更低的成本，但與其他雲提供商的 PaaS 相比，您可以使用它們處理的用例範圍有限。

繼續使用現代替代品。

私有云上的 PaaS

最近出現的一類 PaaS 產品，如Fly、Render和Railway，填補了停滯不前的 Heroku 和公共雲提供商產品日益複雜的格局所造成的空白。

飛行 vs. 渲染 vs. 鐵路

雖然在尋找類似 Heroku 的體驗時，渲染、飛行和鐵路經常相互競爭，但它們並不是近乎對等的。所以首先，讓我們將它們相互比較：

• 與 Fly 或 Rail 相比，Render 更像 Heroku，也就是在開發人員體驗和功能（如文檔、儀表板、CLI 等）方面更加完善。
• Render支持的區域比Fly少得多。沒有關於鐵路支持的地區的信息。
• Fly and Render 的定價很複雜。令人高興的是，Railway 的定價是基於使用量的，並提供慷慨的免費套餐。
• （截至目前）Fly 和 Render 都提供完全託管的 Postgres。Railway 支持與 Postgres 和其他一些數據庫的無配置集成，但這些集成都不是完全託管的。
• 沒有飛行、渲染或鐵路支持隊列。因此，它們不適合需要這些功能的用例。
• Render 和 Railway 都支持 Monorepos；飛沒有。

我們的建議

如果您已經在使用 Elastic Beanstalk 並且正在考慮遷移以實現靈活性或管理更大的規模，那麼 Fly、Render 或 Rail 都不適合。事實上，它們可能更具限制性。

但是，如果您正在尋找您的第一個 PaaS，您應該了解以下內容：

• Fly 與其他 PaaS 一樣針對邊緣應用程序進行了優化，如果您正在構建這樣的應用程序，它是您的最佳競爭者。
• （截至目前）Fly、Render 或 Railyway 非常適合運行靜態網站、構建簡單的 CRUD 應用程序或不需要數據庫的應用程序（假設您的運行時受支持）等用例。
• 由於它們都支持 docker 映像，因此您的鎖定相當受限於它們的專有功能。因此，在評估它們時，鎖定不應成為問題。
• 除非您希望使用 Fly-only 功能，否則 Render and Railway 對開發人員更友好，並且可能更面向未來。
• 鐵路公司的簡單定價為在其他人之前嘗試它提供了理由。

公共雲上的容器原生 PaaS

容器原生 PaaS 是一種無服務器、完全託管的服務，用於部署容器化應用程序和 API。

與舊版 PaaS 一樣，您可以提供源代碼或容器映像。他們負責部署、升級、負載平衡、擴展、安全等，因此您可以專注於交付業務價值。

但與傳統的 PaaS 不同，它們經過優化，不僅可以構建和託管 Web 和移動應用程序，還可以構建和託管 API、微服務、長時間運行的流程、後台任務和事件驅動的應用程序。

公共雲上有三個值得注意的容器原生完全託管的 PaaS：Google Cloud Run（2019 年 11 月正式推出）、AWS App Runner（2021 年 5 月推出）和Azure Container Apps（2022 年 5 月正式推出）。

Cloud Run vs. App Runner vs. Container Apps

• 雖然它們都可以從容器映像和源代碼進行部署，但它們各自對支持的映像類型、源代碼存儲庫和語言運行時都有不同的限制。
• Cloud Run支持的語言比Container Apps和App Runner更多。
• Cloud Run和Container Apps支持 HTTP/2、WebSockets 和 gRPC，但App Runner 不支持。
• Cloud Run 和 Container Apps 支持縮減到 0，而App Runner 不支持。
• App Runner和Cloud Run對後台作業的支持並不理想，但 Container Apps 聲稱支持它們。
• Cloud run 支持藍/綠、金絲雀和滾動部署。容器應用僅支持藍/綠和金絲雀部署。但是 App runner 不支持其中任何一個。
• 容器應用程序支持單個服務中的多個容器，但 Cloud Run 和 App Runner 不支持。
• 鎖定
• 幾乎無鎖定 Cloud Run：基於開源的 KNative。Cloud Run 只是 KNative 之上的一層，它是開源的。因此，您可以使用 KNative 定義在任何 K8S 集群中部署您的容器。
• 容器應用程序：您唯一的投資是創建容器映像，然後運行一些命令來部署它。此外，它由開源的 Kubernetes 提供支持。因此，如果您選擇遷移，您將能夠相對輕鬆地進行遷移。
• App Runner：它在 ECS Fargate 上運行，ECS Fargate 是專有的 AWS 產品，但您的投資僅限於提供容器映像，而它負責其餘部分（作為 PaaS）。因此，如果您選擇遷移，幾乎不會付出任何努力。
• Cloud Run 中的自動擴縮功能開箱即用 - 您無需指定任何規則 - 基於其為每 100 個並發請求創建副本的默認行為。但是，App Runner 和 Container Apps 都要求您指定自動縮放規則。

我們的建議

• 每個 App Runner、Container Apps、Cloud Run、Fly 和 Render 都是相對較新的 PaaS，因此還沒有經過實戰測試。
• 雖然它們都是相對較新的，但 Fly 和 Render 將不可避免地比它們的容器原生公共雲對應物更具限制性，因為公共雲具有廣泛的產品集，您可以使用它們來解決幾乎任何用例。這可能不是解決它的好方法，但它不會阻止你。相反，一旦你在 Fly 或 Render 的能力上碰壁，你就必須擺脫它們。
• 如果您正在尋找您的第一個 PaaS，則應根據您的用例和團隊技能對它們進行評估。
• 但是，如果您希望從 Elastic Beanstalk 遷移到更大的規模靈活性，請評估 App Runner 和 AWS 的 CaaS （稍後會詳細介紹）。

公共雲上的容器即服務 (CaaS)

以上所有 PaaS 選項都允許您開發和部署應用程序，而無需構建、管理和維護基礎架構。容器原生 PaaS 幾乎與 CaaS 相同，只是在某些情況下，正如我們將看到的，CaaS 提供了更多控制。

這種容器原生 PaaS 的抽像在一開始對大多數初創公司來說效果很好，但是如果在某些時候您需要更多的控制權，您將需要評估唯一另一個值得注意的 CaaS 產品：ECS。讓我們來看看它的一些顯著優點和缺點：

AWS ECS（帶或不帶 Fargate）

• 在您可以在其上部署任何東西之前，需要組裝數十個部件。所以，用戶體驗是不愉快的。
• 在 ECS 上設置自動縮放很複雜（就像其他使用它的體驗一樣）。
• 完全專有並迫使您完全依賴 AWS；您需要創建的資源數量和編寫應用程序定義的格式可確保我們鎖定在 AWS 中。如果你選擇它，你會發現搬出去非常困難。但同樣，鎖定需要根據它對您來說容易的事情進行評估。
• 其專有性質也導致其缺乏社區支持。

注意：我們沒有將Azure 容器實例 (ACI)作為替代方案，因為它不支持水平自動縮放。垂直縮放也是純手動的。您所能做的就是運行彼此隔離的單個實例。因此，ACI 不能用於任何應用程序的生產，除非應用程序的單個實例足以滿足您的用例。

我們的建議

• 無論您的用例如何，都完全跳過 ACI。
• 如果您已經在 AWS 上並且您的用例不適合 Kubernetes，請針對運行託管容器的 App Runner 評估 ECS。
• ECS 為 App Runner 提供了更大的靈活性，但代價是您需要進行更多的管理工作。例如，它可以在單個服務中運行多個容器，而 App Runner 則不能。
• ECS 低於標準的開發人員體驗需要大量的設置時間。你應該為此做好心理準備。
• 如果您的目標是僱傭零操作，則不建議使用 ECS。
• 如果 AWS 不是限制因素，Cloud Run 是最適合部署容器化應用程序的開發人員。它具有最少的鎖定，並且是運行無服務器和託管容器的最不干涉的方式。我們強烈建議您對其進行評估。

Kubernetes 即服務 (KaaS) 或託管 Kubernetes

如果想要從 PaaS 遷移以實現靈活性和可擴展性，從邏輯上講，CaaS 將是下一步。但是一些用例也需要考慮 Kubernetes。KaaS 或託管 Kubernetes 服務，例如GKE、EKS和AKS，抽象了控制平面管理，因此比直接使用 Kubernetes 更容易使用。

但是您應該了解哪些信息才能做出更明智的決定？

• Kubernetes 是一個開源的容器編排系統。與 ECS 一樣，CaaS 具有專有的容器編排系統——它們對 Kubernetes 的主要缺點。（不過，Cloud Run 和 Azure 容器應用程序不會因此受到影響，因為 Kubernetes 為它們提供了支持）
• KaaS 的偉大之處在於它是 Kubernetes——它是開源的，擁有大量社區支持，以及用於解決常見用例的工俱生態系統不斷增長——因此具有最小的鎖定和無限的可擴展性。
• 雖然 KaaS 簡化了控制平面的管理，但它仍然將工作節點的管理——例如昇級和網絡連接留給你。如此巨大的開銷需要一個具有專業 Kubernetes 知識的專門團隊。

我們的建議

• 評估您的用例是否需要 Kubernetes，或者容器是否適合您（通過容器原生 PaaS 或 CaaS）。
• 如果您決定繼續使用 Kubernetes，請評估您是否有團隊來運營 GKE、EKS 和 AKS 等 KaaS。
• 總的來說，GKE 是目前最成熟的 KaaS，也是我們推薦的。

如果您今天沒有時間和資源來支持 KaaS，但決定走 Kubernetes 的道路，那麼 KaaS、CaaS 和 PaaS 之間可能會有一個中間地帶。

PaaS、CaaS 和 KaaS 之間的中間地帶

PaaS、CaaS 和 Kaas 之間的中間地帶將利用它們各自的最佳特性，並且不會有各自的限制。

• 與 KaaS 或 CaaS 不同，並且與 PaaS 完全一樣——它將是完全託管和無服務器的。
• 與專有的 CaaS 或 PaaS 不同，它基於 Kubernetes 等開源工具。
• 這不會將您綁定到特定的雲提供商或其工具。
• 這為您提供了集成和利用用於日誌記錄、監控、存儲等的第三方工具的龐大生態系統的空間。

在Argonaut，我們正在嘗試構建這樣一個平台。Argonaut 是您的雲帳戶之上的一個編排層（抽象）。換句話說，它操作您的雲帳戶。

• 它是完全管理的
• 它是容器原生的
• 它原生支持使用 KaaS 或託管 Kubernetes，如 EKS（GKE 支持將在幾週內推出）和 FaaS，如AWS Lambda（雲功能支持即將推出）。
• 您可以在使用 Argonaut 部署的應用程序上運行任何helm chart。
• 它有一個擴展的第三方插件生態系統，用於監控、日誌記錄、搜索等。例子包括Datadog、Prometheus、ELK等。

總結

當遷移到使用 PaaS 或 CaaS 操作基礎架構的任何新方式時，一個好的經驗法則是使用最高級別的抽象來解決您的問題，而不會對工作負載施加任何不必要的限制。如果您是操作新手或應用工程師，我們建議您：

• 從容器原生 PaaS 開始，然後慢慢過渡到自以為是的 CaaS 或 KaaS。這有助於您快速入門，引導您的知識，減少採用最佳技術的障礙，並幫助您通過嵌入式默認值學習良好實踐。
• 隨著時間的推移，隨著您知識深度的增加，您可以開始擺弄默認設置，甚至直接使用本機技術。

腳註

1. Heroku 的定價是按 dyno 計價的，即 Heroku 用於在後端的 EC2 之上運行的容器。由於 Heroku 不運行底層基礎設施堆棧（在 AWS 上），因此您需要為 dynos 和 AWS 為基礎設施支付總共的 Heroku。與 Cloud Run、Container Apps 或 App Runner 相比，您只需為作業執行的工作負載付費，而不為流量付費。因此它們比 Heroku 便宜得多。

鏈接：https ://medium.com/faun/the-top-elastic-beanstalk-alternatives-for-startups-in-2022-f09f2c636260

#devops #aws #kubernetes #aruze 

¿Qué Es DevTestOps? ¿Cómo Funcionan DevOps Y TestOps?

La tecnología siempre está mejorando y los desarrolladores siempre están tratando de encontrar formas mejores y más fáciles de mejorar el software. Así es como surgió DevOps y, con el tiempo, DevTestOps surgió como una nueva estrategia.

Hoy en día, empresas como Spotify aplican DevTestOps en la producción de software, lo que les facilita actualizar, probar e implementar cualquier cambio de forma rápida y sencilla.

En este artículo, veremos DevTestOps, sus objetivos y procesos. También veremos cómo comenzar con DevTestOps, las mejores prácticas y por qué una empresa debería adoptar DevTestOps.

Antes de sumergirnos en DevTestOps, veamos qué son DevOps y TestOps y cómo funcionan.

¿Qué son DevOps y TestOps?

DevOps es una combinación de Desarrollo y Operaciones. DevOps se introdujo en el ciclo de vida del desarrollo de software debido a la necesidad de un desarrollo continuo del producto. Ayuda a los equipos a integrar e implementar actualizaciones de software más fácilmente.

TestOps implica llevar a cabo grandes conjuntos de pruebas de automatización en todo el software para que el software sea altamente eficiente con menos errores.

Inicialmente, DevOps se introdujo en equipos de software que permitían la colaboración solo entre desarrolladores y operadores. Luego, los probadores llevaron a cabo pruebas hacia el final del desarrollo.

Sin embargo, esto planteó algunos desafíos para el equipo. Especialmente después de trabajar en algún software y concluir que estaba listo para la producción, solo para que los evaluadores lo ejecutaran y descubrieran errores complejos. Fue a través de estos desafíos que surgió DevTestOps.

¿Qué es DevTestOps?

DevTestOps es un patrón y parte del ciclo de vida de desarrollo de software que incluye pruebas, integración e implementación continuas.

En DevTestOps, prueba el producto a lo largo de las diferentes etapas de desarrollo, lo que ayuda a reducir la cantidad de errores en las etapas posteriores.

En DevTestOps, los equipos de desarrollo, pruebas y operaciones trabajan mano a mano para garantizar la calidad y las pruebas adecuadas del producto.

Esto da como resultado una entrega rápida, con pocos o ningún error al final del ciclo de vida del desarrollo del software.

DevTestOps surgió como una versión mejorada de DevOps con TestOps incluido. Esto facilita la creación, implementación y desarrollo de productos de calidad con menos errores.

Objetivos de DevTestOps

DevTestOps tiene objetivos que se denominan manifiestos. Los manifiestos definen los objetivos que espera alcanzar.

Según mabl.com :

"Hay cinco manifiestos de DevTestOps que incluyen:
Pruebas continuas sobre pruebas al final.
Adoptar todas las actividades de prueba sobre solo pruebas funcionales automatizadas.
Probar lo que da valor sobre probar todo.
Pruebas en todo el equipo sobre pruebas en departamentos de pruebas aislados.
Cobertura de productos sobre cobertura de código." (Fuente: mabl.com )

Cómo funciona DevTestOps

Hay varias etapas del proceso DevTestOps. Estas etapas son:

1. Plan: en esta etapa, define los detalles del producto y realiza una verificación cruzada para asegurarse de que todo se alinee con el mercado.
2. Compilación: en esta etapa, compila el programa y lo carga en el repositorio, realiza pruebas unitarias y, si encuentra que el programa no tiene errores, se convierte en la base de código. Puede agregar posibles actualizaciones (sugerencias o mejoras) antes de pasar a la siguiente etapa.
3. Pruebas: en esta etapa, lleva a cabo y analiza todos los casos de prueba. Puede realizar actualizaciones posteriores y probar el programa nuevamente antes de entregarlo y considerarlo listo para su implementación.
4. Lanzamiento: inicia el producto y prueba otras actualizaciones escritas antes de agregarlo al código base.
5. Supervisar: revisa constantemente el producto en busca de comentarios y problemas que se manejan y actualizan de inmediato.

Cómo comenzar con DevTestOps:

Muchas organizaciones ya usan DevOps pero siguen produciendo software con errores. Si desea cambiar a DevTestOps para intentar reducir los errores en su código, estos son algunos pasos que puede seguir.

Agregue pruebas continuas a su hoja de ruta o guía de DevOps:

DevTestOps tiene una cultura similar a DevOps excepto que, en este caso, agrega pruebas continuas. Los probadores deben convertirse en parte del equipo DevOps para que puedan probar el software inmediatamente después de una actualización.

Cree una cadena de herramientas DevTestOps:

Una cadena de herramientas incluye todas las herramientas necesarias para implementar DevTestOps.
Por ejemplo, su cadena de herramientas puede incluir herramientas como Jira, Kubernetes, Selenium, GitHub, Jenkins y más.

Puede asignar roles a diferentes equipos usando estas herramientas para que puedan trabajar de manera efectiva con ellos.

Implemente las herramientas en su organización:

A continuación, deberá enseñar a los equipos cómo implementar estas herramientas y seguir las estrategias que implementó para la producción de software.

Podría agregar funciones de prueba a cada equipo, lo que transformaría la cultura de trabajo y fomentaría la colaboración entre los desarrolladores, evaluadores y operadores de cada equipo.

Automatización:

Debe aplicar la automatización en cada uno de estos procesos, desde la fase de construcción hasta la fase de implementación. Esto ayudará a todos los desarrolladores y evaluadores a trabajar de manera más eficiente.

Hacer mejoras constantes:

Finalmente, puede actualizar constantemente las herramientas y los procesos para adaptarse a las tendencias y actualizaciones relevantes en el espacio tecnológico.

Mejores prácticas para DevTestOps:

Estas son algunas de las mejores prácticas que puede seguir para implementar DevTestOps en su equipo:

• Utilice las herramientas y los marcos adecuados para la integración, las pruebas, la entrega y la implementación. Esto dependerá de lo que funcione mejor para la organización.
• Aplique la automatización en las pruebas, la implementación e incluso en otras etapas también. La automatización ayudará a acelerar el proceso y facilitará que los equipos produzcan más rápido y cumplan con los plazos.
• Todos los equipos deben comunicarse de manera efectiva. Deben promover la colaboración entre equipos para aumentar la comprensión, lo que aumentará la productividad y eliminará la confusión.
• La canalización que comprende la integración continua, las pruebas, la entrega y la implementación debe monitorearse siempre. Si detecta un problema, los equipos pueden realizar cambios e integrar las actualizaciones de inmediato.

¿Por qué debería adoptar DevTestOps?

‌Hay muchas razones para adoptar DevTestOps. En primer lugar, mejora la calidad del código.

También mejora la colaboración entre desarrolladores, probadores y operadores. Al igual que en el manifiesto, las pruebas ya no se realizan en departamentos de pruebas aislados, sino en cada fase.

Además, ahorra el tiempo que se dedica a corregir errores cuando se prueba al final en lugar de en cada etapa.

Y, por último, facilita la implementación y la integración continuas.‌

Conclusión

En un mundo de mejoras tecnológicas constantes, las empresas deben mejorar continuamente su software para cumplir con los estándares del mercado.

Con DevTestOps, es más fácil para los equipos de software realizar actualizaciones y mejorar sus productos.

Fuente: https://www.freecodecamp.org/news/what-is-devtestops/

#devtestops #devops #testops