1660190466
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
1660062060
A tool to bring your existing Azure resources under the management of Terraform.
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.
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.
Precompiled binaries are available at Releases.
brew update && brew install aztfy
go install github.com/Azure/aztfy@latest
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:
terraform
discovered in the PATH
whose version >= v0.12
, then use itterraform
installed at the aztfy
cache directory, then use itterraform
from Hashicorp's release to the aztfy
cache directory(The aztfy
cache directory is at: "<UserCacheDir>/aztfy")
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.
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.
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.
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 ofaztfy
(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.
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.
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>
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.
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.
There are several limitations causing aztfy
can hardly generate reproducible Terraform configurations.
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.
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.
aztfy
, explaining the pros and cons.Author: Azure
Source Code: https://github.com/Azure/aztfy
License: MPL-2.0 license
1659759089
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
1659431406
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
1658793060
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.
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.
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.
Run the tests with:
composer test
Please see CHANGELOG for more information on what has changed recently.
Please see CONTRIBUTING for details.
If you discover any security-related issues, please email security@spatie.be instead of using the issue tracker.
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.
And a special thanks to Caneco for the logo ✨
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
1658739435
✅ 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.
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 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.
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.
By adopting these principles, organizations can improve code quality, achieve a faster time to market, and engage in better application planning.
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:
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.
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.
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.
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.
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.
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.
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.
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 lifecyle stretches from the beginning of software development through to delivery, maintenance, and security. The 10 lifecycle stages are:
DevOps closes the loop and incorporates feedback and learnings from the entire lifecycle into your ongoing iteration.
DevOps describes the work that needs to be done, prioritize it, and track its completion.
DevOps writes code, proposes changes, and discusses these proposals with coworkers.
DevOps automatically tests code to make sure it works correctly.
DevOps stores the software in a state where it can be reused later.
DevOps checks whether the software contains vulnerabilities through static and dynamic tests, fuzz testing, and dependency scanning.
DevOps deploys the software to end users.
DevOps manages infrastructure and software platforms.
DevOps sees the impact of the software is on infrastructure and users. It also provides data to help effectively respond to incidents.
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 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.
Source Code Management | Teams looking for better ways to manage changes to documents, software, images, large web sites, and other collections of code, configuration, and metadata among disparate teams. |
Agile Project & Portfolio Management | Teams looking for a better way of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria at the specified time. |
Continuous Integration (CI) | Teams looking for ways to automate the build and testing processes to consistently integrate code and continuously test to minimise the manual efforts spent in frequent runs of unit and integration tests. |
Continuous Delivery (CD) | Teams looking for ways to automate the build, test and packaging, configuration and deployment of applications to a target environment. |
Shift Left Security | Teams looking for ways to identify vulnerabilities during development with actionable information to empower dev to remediate vulnerabilities earlier in the lifecycle have specific goals and meet specific success criteria at the specified time. |
Monitoring and Feedback | Teams looking for ways to embed monitoring into every deployed version and the impact of application changes to the business value and user experience. |
Rapid Innovation | Teams looking for ways to provide feedback back into the development, test, packaging & deployment stages to complete the loop to integrate dev and ops teams and provide real time feedback from production environments and customers. |
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.
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.
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.
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.
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.
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.
More collaboration leads to real-time feedback and greater efficiency; changes and improvements can be implemented quicker and guesswork is removed.
Improved efficiency and frequent communication between teams shortens cycle time; new code can be released more rapidly while maintaining quality and security.
#devops
1658583786
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
1658572932
Все профессионалы обязаны следовать передовым методам, исходя из своей ответственности, независимо от того, какую роль они выполняют. Это не просто так: сохранить все, что связано с целью указанной ответственности. Конечно, такие практики никогда не бывают легкими, но они приносят блаженство и уверенность в наших результатах.
В этом посте будут представлены лучшие практики и ключевые факторы стратегии миграции в облако.
Планирование
Конечно, прежде чем вы начнете внедрять лучшие практики, вы должны определить, какую стратегию вы будете реализовывать для своего проекта, которая соответствует этой цели ( в данном случае, какая из 7R стратегии миграции в облако ).
Вы должны спланировать каждый шаг, определить роль каждого, определить его сложность, необходимое обучение и ресурсы, которые вам потребуются, инвентарь облачных ресурсов, находящихся в вашем распоряжении в настоящее время, приоритет миграции ( сначала наименее сложный проект ), инструменты для наблюдения, и т.п.
Я считаю этот шаг самым важным. Это даст вам представление о том, кто что будет делать при миграции, и определит, не пропало ли что-то.
Миграция по частям
Мы всегда стремимся опробовать новые технологии и стратегии для наших решений, особенно когда речь идет о миграции в облако.
Я приветствую ваш энтузиазм, но все же рекомендую сделать несколько шагов назад. Мигрировать в облако интересно, но всегда лучше просматривать свой проект с более высокого уровня и определять, в каком порядке его перемещать в облако, исходя из отсутствия в нем зависимостей, что упрощает обслуживание ваших проектов и его сложность. .
Это означает, что вы должны мигрировать такие модули, которые не оставляют следов и не делают другие модули застрявшими и неработоспособными. Просто начните с самых простых проектов, которые не вызывают проектов.
Будут редкие случаи, когда вам потребуется перенести всю инфраструктуру за один раз, поэтому всегда принимайте более строгие меры предосторожности, когда речь идет о большой миграции.
Гибридное облако
Я могу высказать вам свое мнение о том, когда использовать гибридное облако, но на сайте techtarget.com есть гораздо лучшее описание предмета, которое я рекомендую вам прочитать: здесь
Оценивать
Всегда устанавливайте предел, когда дело доходит до усилий и затрат. Это дает вашей команде четкое представление о том, что поставлено на карту, и о том, в каком темпе с этим следует бороться, когда он нарушается на разных этапах.
Конечно, мы не идеальны и можем выйти за рамки этой оценки, но всегда рекомендуется иметь четкое представление о сроках поставки и ограничениях по стоимости.
По моему опыту, они не очень заботятся о расходах, но, пожалуйста, сделайте это. Они, наверное, потом будут жаловаться, почему так дорого, тогда вы можете предоставить доказательства такого утверждения.
Мне нравится следующий сайт с подробным описанием прогнозирования облачных затрат: здесь
Запасной план
Независимо от проекта или его цели, всегда лучше иметь план резервного копирования, а также план восстановления. Наша реализация миграции может дать сбой на любом этапе, и хорошо иметь план B, C и т. д., чтобы все работало так, как предполагается на данном этапе.
Это включает в себя откат к предыдущему стеку и предоставление шагов по устранению незначительных и серьезных проблем.
Пожалуйста, оставьте комментарий с вашим опытом в отношении резервного копирования, это тема, которую я хотел бы узнать от вас больше.
Точность
В большинстве случаев мы связаны практикой выполнения наших задач в быстром темпе, что является неплохим стандартом для применения, но он несет в себе высокий уровень риска при крупномасштабных миграциях.
Мы всегда должны фокусироваться на переносимых компонентах, которые сохраняют свою основную цель, после чего мы можем сосредоточиться на других компонентах, таких как безопасность, скорость, производительность и т. д.
Честно говоря, это стандарт, к которому я все еще привыкаю в первую очередь в своих проектах миграции, но я признаю его приоритет.
Испытайте все без пощады
На этом этапе мы ценим интуицию и усилия нашего тестировщика.
Разработчики и инженеры всегда сосредотачиваются на технической стороне целей проектов. Это здорово, но мы всегда должны фокусироваться на всех аспектах (не только технических), которые может принести наш проект.
Именно здесь тестировщики проявят свой острый глаз и определят, что нужно исправить, а что — оптимизировать.
Аудиторская проверка
Возможно, ваша миграция прошла успешно, но она не исключает возможности пропустить несколько шагов или принять некоторые меры, которые еще предстоит реализовать. Всегда рекомендуется периодически проверять ваш перенесенный проект, чтобы гарантировать, что все работает должным образом.
Кроме того, вы должны рассмотреть аудит безопасности. Ваш проект может быть защищен на ваших физических серверах, но вы должны убедиться, что он соответствует стандартам безопасности в вашей новой облачной среде. К счастью, у всех поставщиков облачных услуг есть служба, которая позволяет вам сделать это с легкостью.
Оставьте комментарий к любому инструменту аудита безопасности, с которым вы работали.
Вывод
Проекты миграции в облако утомительны, а также интересны и сложны. Учитывая, что это большая задача с множеством рисков и новых технических аспектов, мы всегда должны следовать передовым методам, чтобы наши проекты оставались красивыми и чистыми.
Ссылка: https://medium.com/faun/best-practices-for-cloud-migration-8efce9040876
#cloud #devops
1658562085
所有專業人士都必鬚根據自己的職責遵循最佳實踐,無論他們扮演什麼角色。它的存在是有原因的:保持與所述責任目標相關的一切。當然,實施這樣的做法絕非易事,但它確實為我們的成果帶來了幸福和保證。
這篇文章將分享雲遷移策略的最佳實踐和關鍵因素。
規劃
當然,在開始實施最佳實踐之前,您必須確定將為符合該目標的項目實施哪種策略(在這種情況下,雲遷移策略的 7R 中的哪一個)。
您必須計劃每個步驟,確定每個人的角色,確定其複雜性、所需的培訓和您需要的資源、當前可供您使用的雲資產清單、遷移的優先級(最不復雜的項目優先)、可觀察性工具,等等
我認為這一步是最重要的一步。這將為您提供誰將在遷移中做什麼的佈局,並確定是否缺少某些內容。
一點一點地遷移
我們總是渴望為我們的解決方案嘗試新技術和策略,尤其是在遷移到雲方面。
我為你的熱情鼓掌,但我建議你退後幾步。遷移到雲是令人興奮的,但是最好從更高的層次查看您的項目,並根據其缺乏依賴性來確定將其遷移到雲的順序,這為您的項目帶來了易維護性和難度.
這意味著您應該遷移這樣的模塊,這些模塊不會留下痕跡,並使其他模塊陷入困境和失敗。只需從不會導致項目的最簡單的項目開始。
在極少數情況下,您需要一次性遷移整個基礎架構,因此在進行大規模遷移時,請始終採取更高的預防措施和步驟。
混合雲
關於何時使用混合雲,我可以給你我的觀點,但是 techtarget.com 對這個主題有更好的描述,我建議你閱讀:這裡
估計
當涉及到工作量和成本時,請始終設定一個限制。這讓您的團隊清楚地了解什麼是危險的,以及在不同階段發生故障時應該處理的速度。
當然,我們並不完美,我們可能會超出這個估計,但始終建議清楚地了解交貨日期和成本限制。
根據我的經驗,他們不太關心成本,但請這樣做。他們稍後可能會抱怨為什麼它如此昂貴,然後您可以提供有關此類聲明的證據。
我喜歡以下詳細描述云成本預測的網站:這裡
後備方案
無論項目或其目標如何,最好有一個備份計劃以及恢復計劃。我們的遷移實施可能在任何階段都失敗,最好有一個計劃 B、C 等來讓事情在給定階段按預期運行。
這包括回滾到以前的堆棧並提供處理從小到大問題的步驟。
請留下您在備份方面的經驗的評論,這是我想向您了解更多信息的主題。
精確
在大多數情況下,我們受制於快速完成任務的做法,這不是一個糟糕的標準,但它確實為大規模遷移帶來了高風險。
我們必須始終專注於保留其主要目標的遷移組件,一旦完成,我們就可以專注於其他組件,例如安全性、速度、性能等。
老實說,這是我仍然習慣於在我的遷移項目中首先實施的標準,但我確實認識到它的優先級。
毫無憐憫地測試一切
這是我們欣賞測試人員的直覺和努力的步驟。
開發人員和工程師始終關注手頭項目目標的技術方面。這很棒,但我們必須始終關注我們項目可能帶來的所有方面(不僅是技術方面)。
測試人員將在這裡發揮他們敏銳的眼光,確定哪些需要修復,哪些需要優化。
審計
您的遷移可能已經成功,但它不會排除錯過幾個步驟或缺少一些尚未實施的措施的可能性。始終建議定期審核您遷移的項目,以確保一切按預期工作。
此外,您必須考慮安全審計。您的項目在物理服務器上可能是安全的,但您必須確保它符合新雲環境中的安全標準。幸運的是,所有云服務提供商都有一項服務可以讓您輕鬆做到這一點。
對您使用過的任何安全審計工具發表評論。
結論
雲遷移項目既乏味又令人興奮且具有挑戰性。考慮到這是一項艱鉅的任務,具有許多風險和新技術方面,因此我們必須始終遵循最佳實踐以保持我們的項目乾淨整潔。
鏈接:https ://medium.com/faun/best-practices-for-cloud-migration-8efce9040876
#cloud #devops
1658551223
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
1658507719
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â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ế:
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:
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?
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)
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.
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:
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.
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:
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:
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).
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ó:
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.
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?
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.
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 .
Để 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:
Chú thích
Liên kết: https://medium.com/faun/the-top-elastic-beanstalk-alternatives-for-startups-in-2022-f09f2c636260
#devops #aws #kubernetes #aruze
1658493180
Перед разработчиками стартапов почти всегда стоит вопрос о наиболее экономичном способе получения преимуществ облака без необходимости управлять базовыми системами. Много лет назад, когда мы все еще создавали монолиты и использовали инстансы 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 для вашего стартапа, потому что можно принять решение только после рассмотрения нюансов своего варианта использования, набора навыков команды и связанных с этим затрат. Тем не менее, мы надеемся, что этот блог поможет вам ориентироваться в различных технологиях, которые могут помочь вам найти решение для вашего растущего масштаба.
Альтернативы, которые не подходят
Следовательно, в этой статье не признаются следующие практические альтернативы ЭБ:
Переходим к альтернативам.
Устаревшая полностью управляемая PaaS в публичных облаках
Существует 2 решения PaaS, по одному от двух ведущих облачных провайдеров: Google и Microsoft, которые почти эквивалентны Elastic Beanstalk:
Основным преимуществом использования любого предложения PaaS от облачного провайдера, будь то Elastic Beanstalk, App Engine или App Service, является ускорение выхода на рынок за счет устранения накладных расходов на обработку деталей развертывания, выделения ресурсов, балансировки нагрузки, безопасности, масштабирования и мониторинг работоспособности приложений.
Итак, как вы оцениваете их друг против друга?
Несмотря на то, что он такой же многофункциональный и проверенный в боевых условиях, теперь сама Google считает App Engine устаревшим продуктом . Мы включили его в качестве альтернативы, потому что некоторые из вас могли спросить нас, почему, если мы этого не сделали. Сегодня сама Google рекомендует разработчикам App Engine перейти на более современный Cloud Run — родственный сервис App Engine. (подробнее об этом позже)
Если ваше приложение использует технологии Майкрософт, такие как .NET, его просто проще запустить в службе приложений, чем в EB или App Engine. Но опять же, подобно Elastic Beanstalk и App Engine, это устаревшая PaaS. Вам лучше оценить более современные предложения PaaS от Microsoft.
Elastic Beanstalk, App Engine и App Service лучше всего подходят для запуска простых веб-приложений или серверных частей мобильных приложений на бессерверной платформе. Это также устаревшие предложения. Хотя они получают регулярные обновления, за последние несколько лет в них было добавлено несколько примечательных функций. Независимо от того, хотите ли вы выбрать свою первую PaaS или альтернативу существующей настройке Elastic Beanstalk, мы настоятельно рекомендуем вам продолжить чтение, чтобы узнать больше о современных полностью управляемых и бессерверных вариантах, которые также рассчитаны на будущее.
Однако, если вы все еще считаете, что одного из этих PaaS достаточно для вашего случая использования, и хотите выбрать один из них, вот что мы должны сказать. Функции или базовая реализация редко будут определять, какую из них вы выберете, потому что вы можете выполнить любой вариант использования с любой из них (с обходными путями или без них). Таким образом, было бы два способа обдумать ваше решение:
Примечание. Другие более мелкие облачные провайдеры, такие как DigitalOcean, предлагают аналогичные услуги с, вероятно, гораздо лучшей поддержкой клиентов и по более низкой цене, но широта вариантов использования, с которыми вы можете справиться, ограничена по сравнению с PaaS других облачных провайдеров.
Перейдем к современным альтернативам.
PaaS в частных облаках
Класс недавних предложений PaaS, таких как Fly , Render и Railway , появился, чтобы заполнить пробел, созданный застойным Heroku и все более сложным ландшафтом предложений поставщиков общедоступных облаков.
Хотя Render, Fly и Railway часто противопоставляются друг другу при поиске опыта, похожего на Heroku, они не являются почти эквивалентными. Итак, сначала давайте сравним их друг с другом:
Если вы уже используете Elastic Beanstalk и рассматриваете возможность миграции для обеспечения гибкости или увеличения масштаба, ни Fly, ни Render, ни Railway вам не подходят. На самом деле, они могут быть более ограничивающими.
Но если вы ищете свою первую PaaS, вам следует знать следующее:
Контейнерная PaaS в публичных облаках
Контейнерная PaaS — это бессерверная, полностью управляемая служба для развертывания контейнерных приложений и API.
Как и в случае с устаревшей PaaS, вы можете предоставить исходный код или образ контейнера. Они позаботятся о развертывании, обновлении, балансировке нагрузки, масштабировании, безопасности и т. д., поэтому вы можете сосредоточиться на обеспечении ценности для бизнеса.
Но в отличие от устаревших PaaS , они оптимизированы для создания и размещения не только веб-приложений и мобильных приложений, но и API-интерфейсов, микросервисов, длительных процессов, фоновых задач и приложений, управляемых событиями.
Существует три заслуживающих внимания полностью управляемых контейнерных приложения PaaS в общедоступных облаках: Google Cloud Run (общедоступно с ноября 2019 г.), AWS App Runner ( запущено в мае 2021 г.) и Azure Container Apps (общедоступно — май 2022 г.).
Контейнеры как услуга (CaaS) в публичных облаках
Все вышеперечисленные варианты PaaS позволяют разрабатывать и развертывать приложения без необходимости создавать, управлять и поддерживать инфраструктуру. Контейнерно-ориентированная PaaS почти такая же, как CaaS, за исключением того, что в некоторых случаях, как мы увидим, CaaS предлагает больше контроля.
Эта абстракция контейнерной PaaS прекрасно работает в начале для большинства стартапов, но если в какой-то момент вам потребуется больше контроля, вам нужно будет оценить единственное другое заметное предложение CaaS: ECS. Давайте взглянем на некоторые из его заметных плюсов и минусов:
Примечание. Мы не включили Azure Container Instances (ACI) в качестве альтернативы, поскольку она не поддерживает горизонтальное автоматическое масштабирование. Вертикальное масштабирование также чисто ручное. Все, что вы можете сделать, это запустить отдельные экземпляры, которые изолированы друг от друга. Следовательно, ACI нельзя использовать в производстве для любого приложения, если только в вашем случае недостаточно одного экземпляра приложения.
Kubernetes как услуга (KaaS) или управляемый Kubernetes
Логически CaaS будет следующим шагом, если кто-то захочет перейти от PaaS для обеспечения гибкости и масштабируемости. Но некоторые варианты использования также требуют рассмотрения Kubernetes. KaaS или управляемые службы Kubernetes, такие как GKE , EKS и AKS , абстрагируются от управления плоскостью управления и, следовательно, с ними проще работать, чем напрямую с Kubernetes.
Но что вы должны знать об этом, чтобы принять более взвешенное решение?
Если у вас нет времени и ресурсов, чтобы отказаться от KaaS сегодня, но вы решили пойти по пути Kubernetes, может быть золотая середина между KaaS, CaaS и PaaS.
Золотая середина между PaaS, CaaS и KaaS
Золотая середина между PaaS, CaaS и Kaas будет использовать лучшие характеристики каждого из них и не будет иметь соответствующих ограничений.
В Argonaut мы пытаемся построить такую платформу. Argonaut — это слой оркестровки (абстракции) над вашей облачной учетной записью. Другими словами, он управляет вашей облачной учетной записью.
Заключить
При переходе на любой новый способ эксплуатации инфраструктуры с использованием PaaS или CaaS рекомендуется использовать абстракцию самого высокого уровня, которая решит вашу проблему, не накладывая ненужных ограничений на рабочую нагрузку. Если вы новичок в эксплуатации или разработчик приложений, мы рекомендуем следующее:
Сноски
Ссылка: https://medium.com/faun/the-top-elastic-beanstalk-alternatives-for-startups-in-2022-f09f2c636260
#devops #aws #kubernetes #aruze
1658478724
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 :
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 :
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 :
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 ?
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)
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.
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 :
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.
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:
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 :
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).
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 :
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.
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 ?
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.
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.
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 :
Notes de bas de page
Lien : https://medium.com/faun/the-top-elastic-beanstalk-alternatives-for-startups-in-2022-f09f2c636260
#devops #aws #kubernetes #aruze
1658464252
初創公司的開發人員幾乎總是面臨著如何以最經濟有效的方式獲得云優勢而無需管理底層系統的問題。多年前,當我們還在構建單體應用程序並使用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 替代方案:
轉向替代品。
公共雲上的傳統全託管 PaaS
有 2 種 PaaS 解決方案,其他兩大雲提供商各自提供:Google 和 Microsoft,它們幾乎等同於 Elastic Beanstalk:
使用任何云提供商的 PaaS 產品(無論是 Elastic Beanstalk、App Engine 還是 App Service)的主要好處是通過消除處理部署、容量配置、負載平衡、安全性、擴展和應用程序健康監控。
那麼,您如何評價它們之間的對比呢?
雖然它功能豐富且經過實戰考驗,但現在 Google 自己認為App Engine 是一個遺留產品。我們將它作為替代方案包括在內,因為你們中的一些人可能會問我們為什麼不這樣做。今天,谷歌自己建議 App Engine 開發人員遷移到更現代的Cloud Run ——App Engine 的姊妹服務。(稍後會詳細介紹)
如果您的應用程序使用 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 中的一種足以滿足您的用例,並且想要選擇其中一種,那麼這就是我們要說的。特性或底層實現很少會決定你選擇哪一個,因為你可以用它們中的任何一個來完成任何用例(有或沒有變通方法)。因此,將有兩種方式來考慮您的決定:
注意:其他較小的雲提供商(如 DigitalOcean)提供類似的服務,可能提供更好的客戶支持和更低的成本,但與其他雲提供商的 PaaS 相比,您可以使用它們處理的用例範圍有限。
繼續使用現代替代品。
私有云上的 PaaS
最近出現的一類 PaaS 產品,如Fly、Render和Railway,填補了停滯不前的 Heroku 和公共雲提供商產品日益複雜的格局所造成的空白。
雖然在尋找類似 Heroku 的體驗時,渲染、飛行和鐵路經常相互競爭,但它們並不是近乎對等的。所以首先,讓我們將它們相互比較:
如果您已經在使用 Elastic Beanstalk 並且正在考慮遷移以實現靈活性或管理更大的規模,那麼 Fly、Render 或 Rail 都不適合。事實上,它們可能更具限制性。
但是,如果您正在尋找您的第一個 PaaS,您應該了解以下內容:
公共雲上的容器原生 PaaS
容器原生 PaaS 是一種無服務器、完全託管的服務,用於部署容器化應用程序和 API。
與舊版 PaaS 一樣,您可以提供源代碼或容器映像。他們負責部署、升級、負載平衡、擴展、安全等,因此您可以專注於交付業務價值。
但與傳統的 PaaS 不同,它們經過優化,不僅可以構建和託管 Web 和移動應用程序,還可以構建和託管 API、微服務、長時間運行的流程、後台任務和事件驅動的應用程序。
公共雲上有三個值得注意的容器原生完全託管的 PaaS:Google Cloud Run(2019 年 11 月正式推出)、AWS App Runner(2021 年 5 月推出)和Azure Container Apps(2022 年 5 月正式推出)。
公共雲上的容器即服務 (CaaS)
以上所有 PaaS 選項都允許您開發和部署應用程序,而無需構建、管理和維護基礎架構。容器原生 PaaS 幾乎與 CaaS 相同,只是在某些情況下,正如我們將看到的,CaaS 提供了更多控制。
這種容器原生 PaaS 的抽像在一開始對大多數初創公司來說效果很好,但是如果在某些時候您需要更多的控制權,您將需要評估唯一另一個值得注意的 CaaS 產品:ECS。讓我們來看看它的一些顯著優點和缺點:
注意:我們沒有將Azure 容器實例 (ACI)作為替代方案,因為它不支持水平自動縮放。垂直縮放也是純手動的。您所能做的就是運行彼此隔離的單個實例。因此,ACI 不能用於任何應用程序的生產,除非應用程序的單個實例足以滿足您的用例。
Kubernetes 即服務 (KaaS) 或託管 Kubernetes
如果想要從 PaaS 遷移以實現靈活性和可擴展性,從邏輯上講,CaaS 將是下一步。但是一些用例也需要考慮 Kubernetes。KaaS 或託管 Kubernetes 服務,例如GKE、EKS和AKS,抽象了控制平面管理,因此比直接使用 Kubernetes 更容易使用。
但是您應該了解哪些信息才能做出更明智的決定?
如果您今天沒有時間和資源來支持 KaaS,但決定走 Kubernetes 的道路,那麼 KaaS、CaaS 和 PaaS 之間可能會有一個中間地帶。
PaaS、CaaS 和 KaaS 之間的中間地帶
PaaS、CaaS 和 Kaas 之間的中間地帶將利用它們各自的最佳特性,並且不會有各自的限制。
在Argonaut,我們正在嘗試構建這樣一個平台。Argonaut 是您的雲帳戶之上的一個編排層(抽象)。換句話說,它操作您的雲帳戶。
總結
當遷移到使用 PaaS 或 CaaS 操作基礎架構的任何新方式時,一個好的經驗法則是使用最高級別的抽象來解決您的問題,而不會對工作負載施加任何不必要的限制。如果您是操作新手或應用工程師,我們建議您:
腳註
鏈接:https ://medium.com/faun/the-top-elastic-beanstalk-alternatives-for-startups-in-2022-f09f2c636260
#devops #aws #kubernetes #aruze
1658338620
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.
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.
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.
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 )
Hay varias etapas del proceso DevTestOps. Estas etapas son:
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.
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.
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.
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.
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.
Finalmente, puede actualizar constantemente las herramientas y los procesos para adaptarse a las tendencias y actualizaciones relevantes en el espacio tecnológico.
Estas son algunas de las mejores prácticas que puede seguir para implementar DevTestOps en su equipo:
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.
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/