Share this
by Seven Peaks on Mar 15, 2021 5:22:00 PM
Meet Fukiat, Partner Specialist at Microsoft (Thailand), who is a highly Experienced Technical Evangelist with a demonstrated history of working in the computer software industry.
His core skills include Data Analytics, Linux, Enterprise Software, Enterprise Architecture, Azure Application Development and Customer Relationship Management (CRM).
Fukiat will be discussing how to Continuously deploy a containerized app to “Azure App Service” through introducing a deployment of containerized App to “App Service – Web App for Containers” by leveraging GitHub Actions
In this article, we will uncover the full journey through Azure web applications; from starting with static web apps to landing NoSQL applications using the Azure Cosmos DB platform.
What is Azure Cosmos DB?
Azure Cosmos DB is a NoSQL Database. It is a PaaS, platform as a service, provided by Azure. What makes Azure Cosmos DB amazing is that it has the ability to be globally distributed with one click. Moreover, it gives to the users the options to be billed by two execution models, provisioned or server less.
The features which Azure Cosmos DB gives to you is the ability to manage conflicts, merge procedures, triggers, user-defined functions, and stored procedures. Conflicts and merge procedures are the way how Cosmos DB manages the conflicts automatically.
However, you can define your custom option to manage the conflicts. Then, when there are some conflicts, Cosmos DB will apply those merge procedures. Cosmos DB is designed to globally scale. So think that someone in the same moment adds a new item to the container that needs to be managed, a conflict will need to be resolved.
Cassandra API – Multi key-values model
Cassandra API, with the multi key-values model, where a value can be a recursive key-value structure. So, in Cassandra you have a key, associated with this key you can have a column that can contain only one value or column that can contain multiple values and it is called column family. This is pretty useful for mapping the many-to-many relationships. There are some limitations, but it is convenient when your data model has a lot of many-to-many or one-to-many relationships.
Gremlin API – Graph model
A graph is a mathematical model based on two simple objects: vertices (edges or nodes) and edges where each edge can be bidirectional or unidirectional.
Storage Table API
In the Azure storage account, you have a feature, a service that is called the storage table, that is the key value model. And now is included into the Azure Cosmos DB. This API is very helpful in the IoT context because the price of the huge amount of data is more convenient than the storage account table.
Azure Cosmos DB – First Contact
First contact, what we have to do, to do what we want to do, and avoiding what we don’t want to do.
Product Catalog
In the product catalog, you choose the Core API because you have semi-structured data for the products which you have: unique code, product name, description, one or multiple sellers. After that, according to the time lapse you will have other not-common values which can be used or not.
Therefore, you need a good capability to filter and sort the products during the retrieval phase like a lot of E-Commerce already did such as Lazada, Agoda, Shopee, etc. Using the Core/SQL API in Cosmos DB you will reduce to simple queries all the possible optimization and complexities for these operations.
Order History
For order history, it is better to use MongoDB. This is because, first, there is no search, you will load the document by its code or key. Secondly, by the data structures. One order is like one document, it is already pretty structured: there is the seller, the buyer, the items which you ordered, inside each item there is a quantity, description, unit price, etc.
Web Analytics
Web analytics is a classic example for collecting the data that comes from different sources using Cassandra API. You have the ability to collect all the data that comes from your website, classified by section, browser, path of the page, interval between the click, loading page, and so on. This kind of key-values data has one key because it’s about yourself or about your session, for example. All the data can be the value that you can collect and store in the Azure Cosmos DB using the Cassandra API.
Recommendation Engine
Gremlin API as graph API is the best option when you have to implement a system that should give you some suggestions, the suggestion works as our brain, following the idea association. For example, I like chocolate cake. If you like the chocolate cake, you like the cake and the chocolate. Focusing on chocolate, you can have white or dark chocolate. Now, moving on to the dark.
There is another vertice that can bring it into the cake or give me another sweet with the dark chocolate. This is simple right? The results come by traversing the graph to suggest the chocolate cake.
IoT system
The IoT system should use the Storage Table API. You should use store only because in the IoT the first thing you have to do is store the data you received. Second, the minimum of the structural data, you have one id, one partition key, and one timestamp. The rest is the data that come from your sensor from your IoT input. In addition, you need the huge space.
An example would be the storage of the data for IoT weather forecasts. The weather forecast is a continuous update of the data. On the atmosphere level, there is a high, medium, low zone, and terrain layer. We need to collect all this data somewhere and pass this data periodically. In that way, when the news reports during lunch time, you have one weather forecast. Afterward, when the news report around dinner time, you will have another weather forecast for tomorrow that may change.
The more data you provide for the weather forecast, the more accurate your forecast is. The data for the weather forecast is around 20-50 GB per six hour. Therefore, if you calculate by multiplying to 24 hour, you start to understand the amount of data that you need to have to calculate exactly what the weather of tomorrow is.
Azure Cosmos DB in depth
Azure Cosmos DB has a concept called consistency level. The consistency level consists of five levels which is strong, bounded, session, consistent, and eventual. They decide the level of data synchronization for the same database across the globe.
First, start to order the level by consistency. Strong consistency level means that your data will be synchronized in milliseconds time across all the world regions chosen. The default one is the Session consistency level, meanwhile the weakest one is the eventual, where the data are “eventual” (in the meaning of maybe) synchronized.
To explain the replication and synchronization Azure already did that using the example of the musical notes, and according to Giorgio’s opinion, it is a good example to easily understand these difficult concepts.
How do you pay for Cosmos DB?
Azure charges you the usage of Cosmos DB using the consumption of the request unit used to retrieve or store your data. These are the main three points where you are going to focus on.
Azure charges you the usage of Cosmos DB using the consumption of the request unit used to retrieve or store your data. These are the main three points where you are going to focus on.
What is a request unit?
The cost to do a point read (i.e. fetching a single item by its ID and partition key value) for a 1 KB item is 1 Request Unit (or 1 RU).
First, you need to choose one API model for Azure Cosmos DB. Second, you need to choose the consistency level. Third, you need to choose the throughput for my request unit.
First, consider what you have. For example, I want to use Cosmos DB to migrate my current MongoDB.Yes, done, finish!
Second plan the API according to the data model that you have or you will have, take in consideration all the possible deviation of these API.
Third, think about the usage of these data, how you search, how you insert, how you update, how you delete. Take in serious consideration of the model of the experiment, so go as PoC and decide based on the experiment.
Risk number one, the model doesn’t fit the reality.
Risk number 2, monitoring the production to predict the possible change, how many times the privacy of Facebook changes?
Risk number 3, rewrite the model or PoC because it is not flexible enough. You perform only the product catalog, I cannot perform the login. Why? Because we identify that the login is not the most valuable feature.
Lastly, test as a maniac, this is the key. You MUST test everything, every single flaw, success and the wrong ones, especially the wrong ones, as well as the performance. When you achieve these two points and you think to cover all the possible features that you have, see the report, see the number against Azure Cosmos DB, cross the data and check if you choose well. Otherwise, go back and increase the RU/s and test again.
See your data model, if you cannot understand the right API model then choose the Core API as default. Second, write the PoC. Identify the most valuable features, if you need to write e-commerce, the login and logout is probably not your primary feature that you need to consider to use for Cosmos DB, but the product catalogue can be the first one.
Develop the most valuable features that you identified, start with a minimum of request units per second, depending on the region you choose.
Lastly, test as a maniac, this is the key. You MUST test everything, every single flaw, success and the wrong ones, especially the wrong ones, as well as the performance. When you achieve these two points and you think to cover all the possible features that you have, see the report, see the number against Azure Cosmos DB, cross the data and check if you choose well. Otherwise, go back and increase the RU/s and test again.
Consideration
Migrating to the cloud
First, consider what you have. For example, I want to use Cosmos DB to migrate my current MongoDB.
Yes, done, finish!
Second plan the API according to the data model that you have or you will have, take in consideration all the possible deviation of these API.
Third, think about the usage of these data, how you search, how you insert, how you update, how you delete. Take in serious consideration of the model of the experiment, so go as PoC and decide based on the experiment.
Risk number one, the model doesn’t fit the reality.
Risk number 2, monitoring the production to predict the possible change, how many times the privacy of Facebook changes?
Risk number 3, rewrite the model or PoC because it is not flexible enough. You perform only the product catalog, I cannot perform the login. Why? Because we identify that the login is not the most valuable feature.
Getting to know Azure Static Web Apps
Azure Static Web Apps is one of the new hosting options for static files built on HTML and JavaScript in the Azure Web Apps Family products.
It is like a combination of several services bound together from Azure by offering streamlined full-stack development from source code to global high availability. The workflow of Azure Static Web Apps is tailored to a developer’s daily workflow. Apps are built and deployed based on GitHub interactions.
There is not only Static content that can be deployed in this service but also API.
Features: What will you when using Azure Static Web Apps
- Web hosting for static content like HTML, CSS, JavaScript, and images.
- Integrated API support provided by Azure Functions.
- First-class GitHub integration where repository changes trigger builds and deployments.
- Globally distributed static content, putting content closer to your users.
- Free SSL certificates, which are automatically renewed.
- Custom domains to provide branded customizations to your app.
- Seamless security model with a reverse-proxy when calling APIs, which requires no CORS configuration.
- Authentication provider integrations with Azure Active Directory, Facebook, Google, GitHub, and Twitter.
- Customizable authorization role definition and assignments.
- Back-end routing rules enabling full control over the content and routes you serve.
- Generated staging versions powered by pull requests enabling preview versions of your site before publishing.
Support: What does Azure Static Web Apps support?
Front-End Frameworks – Static Web Apps supports JavaScript and TypeScript front-end apps including those developed with popular frameworks like Vue.js, React, Angular, and more.
Programming Languages for Azure Functions
- Static Web Apps supports JavaScript
- TypeScript
- Python
- C#
- Azure Functions apps.
Continuously deploy a containerized app to Azure App Service
The idea of app services – why do people love app services? For example, they have the concept of a deployment slot. That means, in one website, you can have one slot, two slots, three slots or four slots. For example, the first slot is like a production.
The second slot is like staging or testing, and if you want to swap between staging and production, you can do that. Of course, you can swap back into production. A lot of people love this feature.
And the second one, why is the app service very popular? Because you can even use the web browser to do the configuration, or you can do integration with many kinds of authentication. In addition, The one thing about the fields, for example, they will tightly integrate with a recorded logic app, we call it the App Insights, it allows us to see what happened inside the application if you have the relationship between the application and also other companies.
The reason why the App service is popular is because they also have a built-in daily backup for the source code and the service that is tightly integrated – like a database server. Another reason why they are popular is because if you want to deploy your own website, and you want to use the custom domain name, you need to pay for the custom domain.
However, every website, if you want to have popular websites, you need to implement the implementation of SSL. If your website is really simple, for example, like www.something.com, you can get the benefits of the SSL for free. You don’t need to pay for the certification.
Relating to the website, when we think about an app service, the first thing we think about, we deploy the source code, deploy the program, deploy the code, and the second one, we can deploy the container because the container really got more popular.
I believe Seven Peaks Software also does a lot of implementation on the container, that means with the whole function of App Service, we have a choice, you can deploy the program under the framework, or wrap everything in doctrine. After that, you put Docker image into the app service.
Another good point is that it is integrated with a CI/CD pipeline, for example, like a native Microsoft, we call the Azure DevOps. In addition, if you want to have something else, for example, like a Jenkins, they can also work with another CI/CD pipeline.
For more details on using GitHub Actions, Azure App Service, Docker Container, Azure Container Registry, Node.js + Express.js, and Azure Cosmos DB together. Watch our meetup now!