Architecture, Tản mạn

System Design – Thiết kế Hệ thống

Everything’s a Trade-Off.

Đôi lời tản mạn.
Cuộc đời 1 lập trình viên từ khi bắt đầu với các dòng code, tập tành viết unit test rồi cơ duyên đưa đẩy mình tìm hiểu về clean code, code smell, refactor để có thể viết được những đoạn code sạch hơn. Lên xíu nữa lại bén duyên với design pattern giúp mình viết code dễ maintain hơn, và trông pro hơn. Sau đó, ta tự tin có thể đảm nhận các nhiệm vụ về review code, được tham gia vào quá trình detail design một module hoặc feature nào đó. Giai đoạn này kéo dài khá lâu, khoảng 3,4 năm đầu đời.

Sau giai đoạn đó, sẽ đến giai đoạn mình được assign để design kiến trúc cho cả một hệ thống. Như thường lệ, như một sự may mắn khi tìm hiểu trên Google, ta sẽ tiếp cận được với rất nhiều tài liệu nói về Software Architecture như Clean Architecture hoặc như series bài viết của mình về Architecture ngay từ những ngày đầu tìm hiểu. Chung quy, software architecture cũng giống như những high level pattern để giải quyết những bài toán ở cấp độ cao hơn so với design pattern, vốn ta sẽ liên tưởng ngay đến coding. Những khái niệm như Microservices, Domain Driven Design, Cloud Computing cũng dần dần xuất hiện. Các khái niệm về High Availability, scalability, Reliability, Security ngày càng trở nên quan trọng trong việc thiết kế bất cứ sản phẩm nào.

Những lần được phân công làm pre-sales cùng các “chuyên gia”, có cả dân sale lẫn dẫn senior technical architect lẫn solution architect đã giúp mình ngày càng mở mang tầm mắt.

Tuy nhiên, mình cảm thấy như vậy chưa đủ, các “high level” digram được vẽ ra vẫn chưa thể lột tả được hết ý nghĩa của một system, vẫn còn một khoảng “gap” rất lớn từ các bản thiết kế để đi đến thực tế lúc triển khai, vẫn tồn tại nhiều vấn đề mà khi đi sâu vào chi tiết mới thấy được. Luôn tồn tại một câu hỏi trong đầu mình, đó là làm thế nào để có thể thiết kế được nguyên cả một hệ thống, không chỉ là những bản vẽ mà còn phải giải quyết được các vấn đề mà bản thiết kế vẫn chưa mô tả được. Và liệu mình có bỏ qua những yếu tố nào khi thiết kế không? Đâu là “bài” để mình theo để có thể lý luận được cả một hệ thống?

Nếu không đặt câu hỏi, bạn sẽ không có câu trả lời. Rất may là mình có câu hỏi, và đang tìm kiếm câu trả lời cho những câu hỏi đó.

(Hết phần tản mạn)

System Design – hay Việt ngữ là Thiết kế Hệ thống.

Một keyword vừa quen mà vừa lạ, tưởng không lợi hại nhưng lợi hại không tưởng.
Quen là một Thiết kế Hệ thống thì ai cũng được học ở trường, nhưng nội dung nó dạy gì thì quên mất rồi. Lạ là vì từ khi đi làm, mình chưa bao giờ thử search cụm từ đó.

Vậy System Design (khi đi làm) nói về cái gì?

“System design is the phase that bridges the gap between problem domain and the existing system in a manageable way. This phase focuses on the solution domain, i.e. “how to implement?”

System design is the process of designing the elements of a system such as the architecture, modules and components, the different interfaces of those components and the data that goes through that system.

The purpose of the System Design process is to provide sufficient detailed data and information about the system and its system elements to enable the implementation consistent with architectural..”

Types of System Design:

  • Logical Design
  • Physical Design
  • Architectural Design
  • Detailed Design
  • Conceptual Data Modeling
  • Entity Relationship Model

Elements of a System

  • Architecture – This is the conceptual model that defines the structure, behavior and more views of a system. We can use flowcharts to represent and illustrate the architecture.
  • Modules – This are components that handle one specific tasks in a system. A combination of the modules make up the system.
  • Components – This provides a particular function or group of related functions. They are made up of modules.
  • Interfaces – This is the shared boundary across which the components of a the system exchange information and relate.
  • Data – This the management of the information and data flow.

vân vân, mây mây..

Reference:

Đọc các định nghĩa trên thì cũng chưa thấy gì lợi hại lắm. Nhưng để ý 1 xíu bạn sẽ thấy System Design bao hàm tất cả những bản thiết kế cần thiết để tạo nên một system hoàn chỉnh, từ architecture, module, interface, data flow…

Có thể nói System Design là đẳng cấp cao nhất của design phase. Sau giai đoạn này chúng ta sẽ tiến lên phase Analysis với màn món System Analysis. Con đường trở thành Solution Architect hoặc Sale đang trước mắt chúng ta. Kakaka..

Và nếu may mắn, chúng ta sẽ tiếp cận được với một phương trời mới với rất nhiều những “tài nguyên” phong phú để đắm chìm trong đó. Đó chính là những tài liệu giúp chúng ta tiếp cận với tư duy thiết kế những hệ thống to bự (large scale) trong thế giới thật (real-world) chứ không phải là các triết lý (principle) và pattern suông nữa. (Nếu xem Principle và pattern là linh hồn của giải các bài toán của một hệ thống thì việc đắp da đắp thịt cho hệ thống).

Một số gợi ý cho các bạn tham khảo:

Các tài liệu đó sẽ đưa chúng ta go through các thiết kế của các hệ thống kinh điển như Facebook, Dropbox, Twitter, Instagram,…

Đọc đến đây thì nếu đó là thứ bạn cần thì sẽ không ngần ngại mà rời trang này và tiến vào quá trình trải nghiệm của bản thân ngay lập tức.

Enjoy : )

Architecture, Cloud

[Azure] Architecting Cloud Applications

Introduction

https://docs.microsoft.com/en-us/azure/architecture/guide/

Architecture styles

  • N-tier application
  • Microservices
  • Event-driven architecture
  • Web-queue-worker
  • Big compute
  • Big data

Application design principles

Follow these design principles to make your application more scalable, resilient, and manageable.

  • Design for self healing. In a distributed system, failures happen. Design your application to be self healing when failures occur.
  • Make all things redundant. Build redundancy into your application, to avoid having single points of failure.
  • Minimize coordination. Minimize coordination between application services to achieve scalability.
  • Design to scale out. Design your application so that it can scale horizontally, adding or removing new instances as demand requires.
  • Partition around limits. Use partitioning to work around database, network, and compute limits.
  • Design for operations. Design your application so that the operations team has the tools they need.
  • Use managed services. When possible, use platform as a service (PaaS) rather than infrastructure as a service (IaaS).
  • Use the best data store for the job. Pick the storage technology that is the best fit for your data and how it will be used.
  • Design for evolution. All successful applications change over time. An evolutionary design is key for continuous innovation.
  • Build for the needs of business. Every design decision must be justified by a business requirement.

Five pillars of software quality

  • Cost. Managing costs to maximize the value delivered.
  • DevOps. Operations processes that keep a system running in production.
  • Resiliency. The ability of a system to recover from failures and continue to function.
  • Scalability. The ability of a system to adapt to changes in load.
  • Security. Protecting applications and data from threats.

Cloud Design Patterns

Caterogies

  • Availability
  • Data management
  • Design and implementation
  • Management and monitoring
  • Messaging
  • Performance and scalability
  • Resiliency
  • Security

Patterns

  • Ambassador
  • Anti-corruption Layer
  • Asynchronous Request-Reply
  • Backends for Frontends
  • Bulkhead
  • Cache-Aside
  • Choreography
  • Circuit Breaker
  • Claim Check
  • Command and Query Responsibility Segregation (CQRS)
  • Compensating Transaction
  • Competing Consumers
  • Compute Resource Consolidation
  • Event Sourcing
  • External Configuration Store
  • Federated Identity
  • Gatekeeper
  • Gateway Aggregation
  • Gateway Offloading
  • Gateway Routing
  • Health Endpoint Monitoring
  • Index Table
  • Leader Election
  • Materialized View
  • Pipes and Filters
  • Priority Queue
  • Publisher/Subscriber
  • Queue-Based Load Leveling
  • Retry
  • Scheduler Agent Supervisor
  • Sequential Convoy
  • Sharding
  • Sidecar
  • Static Content Hosting
  • Strangler
  • Throttling
  • Valet Key

Best practices for Cloud application

  • API design
  • API implementation
  • Autoscaling
  • Background jobs
  • Caching
  • Content Delivery Network
  • Data partitioning
  • Data partitioning strategies (by service)
  • Deployment stamp
  • Monitoring and diagnostics
  • Retry guidance for specific services
  • Transient fault handling
Agile, Architecture, Design Pattern, Devops, Methodology, Microservices, OO Design Principles, TDD

InfoQ’s 2019, and Software Predictions for 2020

See full post at: https://www.infoq.com/articles/infoq-2019-retrospective/

Key Takeaways

  • Last month, Google claimed to have achieved quantum supremacy—the name given to the step of proving quantum computers can deliver something that a classical computer can’t. That claim is disputed, and it may yet turn out that we need a better demonstration, but it still feels like a significant milestone.
  • A surprise this year was the decline of interest in Virtual Reality, at least in the context of Smart-phone-based VR. Despite this we still think that something in the AR/VR space, or some other form of alternative computer/human interaction, is likely to come on the market in the next few years and gain significant traction.
  • We expect to see the interest in Web Assembly continue and hope that the tooling for it will start to mature.
  • In our DevOps and Cloud trend report, we noted that Kubernetes has effectively cornered the market for container orchestration, and is arguably becoming the cloud-agnostic compute abstraction. The next “hot topics” in this space appear to be “service meshes” and developer experience/workflow tooling.
  • We’re looking forward to seeing what the open source community and vendors are working on in the understandability, observability, and debuggability space in the context of architectural patterns such microservices and functions(as-a-service).

Development

Java

JavaScript, Java, and C# remain the most popular languages we cover, but we’re also seeing strong interest in Rust, Swift, and Go, and our podcast with Bryan Cantrill on “Rust and Why He Feels It’s The Biggest Change In Systems Development in His Career” is one of the top-performing podcasts we’ve published this year. We’ve also seen a growing interest in Python this year, probably fuelled by its popularity for machine learning tasks.

After a rather turbulent 2018, Java seems to be settling into its bi-annual release cycle. According to our most-recent reader survey Java is the most used language amongst InfoQ readers, and there continues to be a huge amount of interest in the newer language features and how the language is evolving. We also continue to see strong and growing interest in Kotlin.

It has been interesting to see Microsoft’s growing involvement in Java, joining the OpenJDK, acquiring JClarity, and hiring other well known figures including Monica Beckwith.

In the Java programming language trends report, we noted increased adoption of non-HotSpot JVMs, and we believe OpenJ9 is now within the early-adopter stage. As the time we noted that:

“We believe that the increasing adoption of cloud technologies within all types of organisation is driving the requirements for JREs that embrace associated “cloud-native” principles such as fast start-up times and a low memory footprint. Graal in itself may not be overly interesting, but the ability to compile Java application to native binaries, in combination with the support of polyglot languages, is ensuring that we keep a close watch on this project.”

.NET

The release of .NET Core 3 in September generated a huge buzz on InfoQ and produced some of our most-popular .NET content of the year. WebAssembly has been another area of intense interest, and we saw a corresponding surge in interest for Blazor, a new framework in ASP.NET Core that allows developers to create interactive web applications using C# and HTML. Blazor comes in multiple editions, including Blazor WebAssembly which allows single-page applications to run in the client’s web browser using a WebAssembly-based .NET runtime.

According to our most-recent reader survey, C# is the second-most widely used language among InfoQ readers after Java, and interest in C#8 in particular was also strong.

Web Development

Unsurprisingly, the majority of InfoQ readers write at least some JavaScript – around 70% according to the most recent reader survey – making it the most widely used language among our readers. The dominant JavaScript frameworks for InfoQ readers seem to currently be Vue and React. We also saw interest in using Javascript for machine learning via TensorFlow.js.  Away from JavaScript, we saw strong interest in some of the transpiler options. In addition to Blazor, mentioned above, we saw strong interest in Web Assembly, Typescript, Elm and Svelte.

Architecture

It’s unsurprising that distributed computing, and in particular the microservices architecture style, remains a huge part of our news and feature content. We see strong interest in related topics, with our original Domain Driven Design Quickly book, and our more-recent eMag “Domain-Driven Design in Practice” continuing to perform particularly well, and interest in topics like observability and distributed tracing. We also saw interest in methods of testing distributed systems, including a strong performance from our Chaos Engineering eMag, and a resurgence in reader interest in some for the core architectural topics such as API design, diagrams, patterns, and models.

AI, ML and Data Engineering

Our podcast with Grady Booch on today’s Artificial Intelligence reality and what it means for developers was one of our most popular podcasts of the year, and revealed strong interest in the topic from InfoQ readers.

Key AI stories in 2019 were MIT introducing GEN, a Julia-basd language for artificial intelligence, Google’s ongoing work on ML Kit, and discussions around conversational interfaces, as well as more established topics such as streaming.

It’s slightly orthogonal to the rest of the pieces listed here, but we should also mention “Postgres Handles More Than You Think” by Jason Skowronski which performed amazingly well.

Culture and Methods

If there was an overarching theme to our culture and methods coverage this year it might best be summed up as “agile done wrong” and many of our items focused on issues with agile, and/or going back to the principles outlined in the Agile Manifesto.

We also saw continued in interest in some of the big agile methodologies, notably Scrum, with both “Scrum and XP from the Trenches“, and “Kanban and Scrum – Making the Most of Both” performing well in our books department.

We also saw strong reader interest in remote working with Judy Rees’ eMag on “Mastering Remote Meetings“, and her corresponding podcast, performing well, alongside my own talk on “Working Remotely and Managing Remote Teams” from Aginext this year.

DevOps and Cloud

In our DevOps and Cloud trends report, we noted that Kubernetes has effectively cornered the market for container orchestration, and is arguably becoming the cloud-agnostic compute abstraction. The next “hot topics” in this space appear to be “service meshes” and developer experience/workflow tooling. We continue to see strong interest in all of thee among InfoQ’s readers.

A trend we’re also starting to note is a number of languages which are either infrastructure or cloud-orientated. In our Programming Languages trends report, we noted increased interest and innovation related to infrastructure-aware or cloud-specific languages, DSLs, and SDKs like Ballerina and Pulumi. In this context we should also mention Dark, a new language currently still in private beta, but already attracting a lot of interest. Somewhat related, we should also mention the Ecstasy language, co-created by Tangosol founders Cameron Purdy and Gene Gleyzer. Chris Swan, CTO for the Global Delivery at DXC Technology, spoke to Cameron Purdy about the language and the problems it’s designed to solve.

Software Predictions for 2020

Making predictions in software in notoriously hard to do, but we expect to see enterprise development teams consolidate their cloud-platform choices as Kubernetes adoption continues. Mostly this will be focussed on the “big five” cloud providers – Amazon, Google, IBM (plus Red Hat), Microsoft, and VMware (plus Pivotal). We think that, outside China, Alibaba will struggle to gain traction, as will Oracle, Salesforce, and SAP.

In the platform/operations space we’re expecting that service meshes will become more integrated with the underlying orchestration frameworks (e.g. Kubernetes). We’re also hopeful that the developer workflow for interacting with service meshes becomes more integrated with current workflows, technologies, and pipelines.

Ultimately developers should be able to control deploy, release, and debugging via the same continuous/progressive delivery pipeline. For example, using a “GitOps” style pipeline to deploy a service by configuring k8s YAML (or some higher-level abstraction), controlling the release of the new functionality using techniques like canarying or shadowing via the configuration of some traffic management k8s custom resource definition (CRD) YAML, and enabling additional logging or debug tooling via some additional CRD config.

In regards to architecture, next year will hopefully be the year of “managing complexity”. Architectural patterns such microservices and functions(as-a-service) have enabled developers to better separate concerns, implement variable rates of change via independent isolated deployments, and ultimately work more effectively at scale. However, our ability to comprehend the complex distributed systems we are now building — along with the availability of related tooling — has not kept pace with these developments. We’re looking forward to seeing what the open source community and vendors are working on in the understandability, observability, and debuggability space.

We expect to see more developers experimenting with “low code” platforms. This is partly fueled by a renewed push from Microsoft for its PowerApps, Flow, Power BI, and Power Platform products.

In the .NET ecosystem, we believe that Blazor will keep gaining momentum among web developers. .NET 5 should also bring significant changes to the ecosystem with the promised interoperability with Java, Objective-C, and Swift. Although it is early to say, Microsoft’s recent efforts on IoT and AI (with ML.NET) should also help to raise the interest in .NET development.  Related we expect to see the interest in Web Assembly continue and hope that the tooling hear will start to mature.

Despite the negative news around VR this year, we still think that something in the AR/VR space, or some other form of alternative computer/human interaction, is likely to come on the market in the next few years and gain significant traction, though it does seem that the form factor for this hasn’t really arrived.

Architecture, Cloud, Methodology, Microservices

What Is Cloud Native, Anyway?

Sam Newman, author of Building Microservices, opened the day’s talks by tackling the question directly. He reviewed the different ways that people define cloud native and unpicked whether they were useful.

“It’s a buzz-worthy term that has no real, good, formal definition,” says Sam. “A lot of people conflate many things in the term cloud native. In my talk, I came back down to the sub-characteristics we commonly talk about for cloud-based applications: they’ve got to be built for scale, there must be some concepts of fault tolerance, and they need to have high degrees of automation”.

While there are attempts to build vendor-agnostic, cloud native application platforms, even they are tied to a PaaS or “underlying container orchestrator”. So to be cloud native means to build for the specifics of your chosen platform. Whether it’s AWS, GCE or a private Kubernetes cluster, each has its own peculiarities.

Cloud native comes down to three things:

  • Build microservices: before anything else, move to microservices, as they’ll have the biggest impact
  • Use existing services: don’t re-implement anything that is available as a cloud-based service
  • Automate everything: automated testing, continuous integration, continuous delivery

I think it’s probably an overloaded term,” says Nicki, “For me, cloud native is really about making sure that the way you approach building your applications makes first class citizens out of being able to efficiently utilize your platform to scale, distribute and manage your systems in an automated way. At the moment, that’s predominantly cloud based“. That’s Nicki Watt’s take

Source: https://dzone.com/articles/what-is-cloud-native-anyway

Architecture

What is cloud-native? The modern way to develop software

Cloud-native computing takes advantage of many modern techniques, including PaaS, multicloud, microservices, agile methodology, containers, CI/CD, and devops

The term “cloud-native” gets thrown around a lot, especially by cloud providers. Not only that, but it even has its own foundation: the Cloud Native Computing Foundation (CNCF), launched in 2015 by the Linux Foundation.

‘Cloud-native’ defined

In general usage, “cloud-native” is an approach to building and running applications that exploits the advantages of the cloud computing delivery model. “Cloud-native” is about how applications are created and deployed, not where. It implies that the apps live in the public cloud, as opposed to an on-premises data center.

The CNCF defines “cloud-native” a little more narrowly, to mean using open source software stack to be containerized, where each part of the app is packaged in its own container, dynamically orchestrated so each part is actively scheduled and managed to optimize resource utilization, and microservices-oriented to increase the overall agility and maintainability of applications.

“A cloud native app is architected specifically to run in the elastic and distributed nature required by modern cloud computing platforms,” says Mike Kavis, a managing director with consulting firm Deloitte. “These apps are loosely coupled, meaning the code is not hard-wired to any of the infrastructure components, so that the app can scale up and down on demand and embrace the concepts of immutable infrastructure. Typically, these architectures are built using microservices, but that is not a mandatory requirement.”

Cloud-native app development typically includes devopsagile methodologymicroservicescloud platforms, containers like Kubernetesand Docker, and continuous delivery—in short, every new and modern method of application deployment.

Because of this, you really want to have a platform-as-a-service (PaaS) model. A PaaS is not required, but it makes things a lot easier. The vast majority of cloud customers start out with infrastructure-as-a-service (IaaS), which helps abstract their apps from the underlying hardware. But PaaS adds an extra layer to abstract the underlying OS, so you can focus entirely on the business logic of your app and not worry about making OS calls.

The challenges of cloud-native computing

One of the big mistakes customers make is trying to lift and shift their old on-premises apps to the cloud, Mann says. “Attempting to take existing applications—especially monolithic legacy applications—and move them onto a cloud infrastructure will not take advantage of essential cloud-native features.”

Instead, you should look to do new things in new ways, either by putting new cloud-native applications into new cloud infrastructure or by breaking up existing monoliths to refactor them using cloud-native principles from the ground up.

You also need to dispense with your old developer methods. The waterfall model certainly won’t do, and even agile development might not be enough. So, you must adopt new cloud-native approaches like minimum viable product (MVP) development, multivariate testing, rapid iteration, and working closely across organizational boundaries in a devops model.

There are many aspects to being cloud-native, including infrastructure services, automation/orchestration, virtualization and containerizationmicroservices architecture, and observability. All of these mean a new way of doing things, which means breaking old habits as you learn the new ways. So do it at a measured pace.

Source: https://www.infoworld.com/article/3281046/what-is-cloud-native-the-modern-way-to-develop-software.html

Architecture

Serverless Architecture

serverless-architecture

In the beginning, there was bare metal, and it was good.

Single-tenant servers were fast, reliable and secure — beholden only to their master. Verily, though, also cumbersome to provision and scale. The need for agility and scalability begat VMs, and cloud providers brought unto us infrastructure as a service (IaaS), and lo self-service in the cloud was born. Upon this fertile land arose Amazon Web Services, orchestration, and infrastructure as code (IaC); then also containerization came to pass, which begat platform as a service (PaaS) architecture. And lo all was well upon the land … Except for developers crying forth in want of language agnostic endpoints, horizontal scalability and the ability to pay for the real-time consumption of services.

1_DYoadhgfpZCMRCMKNUpQ6A

In response to their pleas, at last, a great gift was bestowed upon the world: serverless computing, also often known as function as a service (FaaS). Runtimes which execute applications but do not store data. Meaning, a cloud provider like AWS, Google Cloud or Microsoft Azure dynamically manages the assignment and distribution of resources.

Serverless is pay-as-you-go, based on actual consumption rather than pre-purchased services based on guesswork. This is infrastructure as it was meant to be, emerging right before our eyes in 2018.

It’s Not Moonbeams

First: The name is totally misleading. Serverless computing still requires servers. There aren’t, like, secret magical moonbeams powering everything.

The term arose because the server management and capacity planning decisions are completely hidden. Serverless is “serverless” in terms of the user/developer never needing to take care of, or even be aware of, any of the infrastructure — the servers are fully abstracted away. Serverless code can be used alongside code deployed in traditional styles, such as microservices — or, applications can be written to be purely serverless and use no provisioned servers at all.

Well, What IS Serverless, Then?

The major difference between traditional cloud computing and serverless computing is that you — the customer needing said computing — don’t pay for unused, or even underutilized, resources. Previously, we had to anticipate capacity and resource requirements and pre-provision for them, whether on in-house data center or in the cloud. In our previous example, however, this would mean spinning up a server in AWS to stand by to execute this image resizing service at any time. In a serverless setup, however, you’re just spinning up some code execution time when, and only when, the function is called.

The serverless computing service takes your functions as input, performs logic, returns your output, and then shuts down. You are only billed for the resources used during the actual execution of those functions.

Pay-as-you-play, and only for resources actually consumed, is obviously a great thing. However, Goasguen and other cloud-native pros stress that the true value of serverless is not cost efficiency, but time efficiency.

Feel the FaaS Platform Power

While Docker has simplified the packaging and dependency handling for distributed application, and Kubernetes is helping enterprise run these apps in production, they still are not yet simple or easy to use. “Dockerfile, infrastructure details, Kubernetes manifests — all of these are still too complicated for a developer-minded audience,” said Bitnami’s Goasguen.

At its core, then, serverless computing works as a Function as a Service platform. Essentially, that’s what AWS Lambda or Google Cloud Function, handling resource management, load balancing and multithreading while the devs get to just focus on their code, and enterprise orgs on their mission.

Yaron Haviv, founder and CTO of iguaz.io, a continuous data platform expressly designed to optimize performance in the cloud, walked The New Stack through the FaaS workflow:

  1. Serverless platforms take functional code — the “function” part of FaaS — plus all its dependencies (required libraries, amount of memory, properties, etc.), and build a containerized application package, usually in the form of a Docker image.
  2. When another platform service, such as an object storage or database wants to trigger the function, or when there is an external HTTP request destined for that function, the serverless platform will direct it to one of the available function microservices. If there are no active microservices available, it will deploy — “cold start” such an instance.
  3. The serverless platform takes care of recovering micro-services upon failure, auto-scaling to fit demand, logging and monitoring function activity and conducting a live rolling upgrade when code is modified. Someone else manages the platform services so that developers can just focus on the “function” aspect.

Are There Serverless Downsides?

For all the benefits, there are some potential FaaS downsides as well. For one, experts say, cloud providers will typically spin down runtime environments that aren’t seeing much use — meaning paradoxically, they also limit the total amount of resources available to you, introducing latency and problems with high-performance. Monitoring, debugging, and security can also tricky with these cloud providers — as they would be with any cloud computing workflow — due to the fact that it all, well, runs in a public cloud that you don’t have access to or control of.

Amazon Lambda has become synonymous with serverless computing, and that is a model most people can wrap their heads around. Thus, while Lamba has blazed the serverless trail, its drawbacks have come to be perceived as the drawbacks of serverless overall:  slow cold start, slow performance, short-lived functions, and a closed set of triggers. These limitations are now assumed to universally apply to all serverless platforms, when in fact those are implementation choices. It is important to note that there are newer serverless platforms, such as Nuclio, which evolved to serve a broader set of use cases. These platforms have fewer restrictions, provide high performance, and can run in multiple clouds or even on premises.

“The geeks love it, but enterprises are still testing the water — they haven’t even gotten used to Docker/K8s, and now there is serverless,” said Haviv. “Like any new technology, it needs to ‘cross the chasm’ from the early adopters — who are typically more agile, more willing to take risks — to the masses. Who need to build trust, see proof points, address concerns like performance, security…”

Obviously, given that serverless tech is emerging and evolving practically day by day, not all aspects can be comfortably known entities. While not necessarily a downside, this factor definitely makes entire boards of directors squirm in their Aeron chairs. “Enterprises simply have to become more agile and take risks, since the digital “transformation” is taking casualties in the form of incumbents who are disrupted by innovators, and Serverless (like other As A Service technologies),” Haviv pointed out.

“The interesting part is that by abstracting away much of the Docker/Kubernetes complexity, serverless can be adopted faster and more easily, even though it’s the newer tech.”

Source: https://thenewstack.io/serverless-101-how-to-get-serverless-started-in-the-enterprise/

Architecture, Cloud

Cloud Native Application (CNA)

Cloud Native App là gì?

Cloud Native App (CNA) là một “buzz word”. CNA là một app “thuần” (từ này hơi sloppy :D) cloud. Dưới góc nhìn high level, nó là app được thiết kế để chạy trên môi trường cloud. Nhìn rộng ra thì nó có thể chạy được trên nhiều môi trường cloud, thậm chí có thể được triển khai theo kiến trúc phân tán (distributed) trên nhiều môi trường cloud để tận dụng tối đa các nguồn lực mà cloud mang lại.

Các bạn có thể tham khảo các thông tin về CNA theo website dưới đây:

https://www.cncf.io/

Dưới đây là loạt bài viết về Cloud Native Application ở trang vietstack.wordpress.com, các bạn có thể vào đó và đọc chi tiết 🙂

Nguồn: vietstack.wordpress.com