AWS Fargate

AWS Fargate is a compute engine for Amazon ECS that allows you to run containers without having to manage servers or clusters. With AWS Fargate, you no longer have to provision, configure, and scale clusters of virtual machines to run containers. This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing. AWS Fargate removes the need for you to interact with or think about servers or clusters. Fargate lets you focus on designing and building your applications instead of managing the infrastructure that runs them.

Amazon ECS has two modes: 

• Fargate launch type
• EC2 launch type

With Fargate launch type, all you have to do is package your application in containers, specify the CPU and memory requirements, define networking and IAM policies, and launch the application. EC2 launch type allows you to have server-level, more granular control over the infrastructure that runs your container applications. 

With EC2 launch type, you can use Amazon ECS to manage a cluster of servers and schedule placement of containers on the servers. Amazon ECS keeps track of all the CPU, memory and other resources in your cluster, and also finds the best server for a container to run on based on your specified resource requirements. You are responsible for provisioning, patching, and scaling clusters of servers. You can decide which type of server to use, which applications and how many containers to run in a cluster to optimize utilization, and when you should add or remove servers from a cluster. EC2 launch type gives you more control of your server clusters and provides a broader range of customization options, which might be required to support some specific applications or possible compliance and government requirements.

Link: https://aws.amazon.com/fargate/

Visual Studio 2019

Version Number: 16.1

Summary of What's New in Visual Studio 2019:

• IDE
• Visual Studio IntelliCode is now generally available and comes installed with any workload that supports C#, C++, TypeScipt/JavaScript, or XAML.
• We have added Per-Monitor Awareness support.
• New codefixes are available for C#.
• Most Recently Used has been added to Visual Studio Search.
• Debugger
• Source Link authentication improvements have been implemented.
• We have added nuget.org symbol server to the list of default symbol servers.
• Time Travel Debugging preview now includes exception stepping support.
• Extensibility
• We have removed the need for .resx file in VSIX projects (BuildTools update).
• VSIX Project template now uses the new SDK version.
• Performance
• You can now experience optimizations to improve the solution load time of very large solutions.
• Template authors can add custom tags to their templates.
• There is now CodeLens support for custom UI.
• We have provided updates to Language Server Protocol implementation.
• We have updated behavior for switching between solutions, folders, and other views.

Snowflake : Data Encryption

Snowflake provides best-in-class key management, which is entirely transparent to customers.

End-to-end encryption (E2EE) is a form of communication in which no one but end users can read the data. In Snowflake, this means that only a customer and the runtime components can read the data. No third parties, including Snowflake’s cloud computing platform or any ISP, can see data in the clear. E2EE minimizes the attack surface. In the event of a security breach of the cloud platform, the data is protected because it is always encrypted, regardless of whether the breach exposes access credentials indirectly or data files directly, whether by an internal or external attacker.

Client-side encryption provides a secure system for managing data in cloud storage. Client-side encryption means that a user encrypts stored data before loading it into Snowflake. The cloud storage service only stores the encrypted version of the data and never includes data in the clear.

Document Link: https://docs.snowflake.net/manuals/user-guide/security-encryption.html

Sharing Data Securely in Snowflake

Secure Data Sharing enables sharing selected objects (tables, secure views, and secure UDFs) in a database in your account with other Snowflake accounts. The principle participants in any data sharing relationship are the provider and one or more consumers. Snowflake enables the sharing of databases through shares, which are created by data providers and "imported" by data consumers. All database objects shared between accounts are read-only (i.e. the objects cannot be modified or deleted, including adding or modifying table data).
With Secure Data Sharing, no actual data is copied or transferred between accounts. All sharing is accomplished through Snowflake’s unique services layer and metadata store. This is an important concept because it means that shared data does not take up any storage in a consumer account and, therefore, does not contribute to the consumer’s monthly data storage charges. The only charges to consumers are for the compute resources (i.e. virtual warehouses) used to query the shared data.
In addition, because no data is copied or exchanged, Secure Data Sharing setup is quick and easy for providers and access to the shared data is instantaneous for consumers:

• The provider creates a share of a database in their account and grants access to specific objects (i.e. tables, secure views, and secure UDFs) in the database. One or more accounts are then added to the share, which can include your own accounts (if you have multiple Snowflake accounts).
• On the consumer side, a read-only database is created from the share. Access to this database is configurable using the same, standard role-based access control that Snowflake provides for all objects in the system.

Shares are named, first-class Snowflake objects that encapsulate all of the information required to share a database. Each share consists of:

• The privileges that grants access to the database and the schema containing the objects to share.
• The privileges that grant access to the specific objects (tables, secure views, and secure UDFs).
• The consumer accounts with which the database and its objects are shared.

Once a database is created (in a consumer account) from a share, all the shared objects are accessible to users in the consumer account. Shares are secure, configurable, and controlled 100% by the provider account:

• New objects added to a share become immediately available to all consumers, providing real-time access to shared data.
• Access to a share (or any of the objects in a share) can be revoked at any time.

Link: https://docs.snowflake.net/manuals/user-guide/data-sharing-intro.html

New Year Greetings 2019

GitHub vs. Bitbucket vs. AWS CodeCommit

	GitHub	Bitbucket	AWS CodeCommit
Description	GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Over three million people use GitHub to build amazing things together.	Bitbucket gives teams one place to plan projects, collaborate on code, test and deploy, all with free private Git repositories. Teams choose Bitbucket because it has a superior Jira integration, built-in CI/CD, & is free for up to 5 users.	CodeCommit eliminates the need to operate your own source control system or worry about scaling its infrastructure. You can use CodeCommit to securely store anything from source code to binaries, and it works seamlessly with your existing Git tools.
Pros	• Open source friendly • Easy source control • Nice UI • Great for team collaboration • Easy setup • Issue tracker • Remote team collaboration • Great community • Great way to share • Pull request and features planning	• Free private repos • Simple setup • Nice ui and tools • Unlimited private repositories • Affordable git hosting • Integrates with many apis and services • Reliable uptime • Nice gui • Pull requests and code reviews • Very customisable	• Free private repos • IAM integration • Pay-As-You-Go Pricing • Repo data encrypted at rest • Amazon feels the most Secure • I can make repository by myself if I have AWS account • Faster deployments when using other AWS services • Does not support web hooks yet! • AWS CodePipeline integration • Codebuild integration
Cons	• Expensive for lone developers that want private repos • Relatively slow product/feature release cadence • Owned by micrcosoft • API scoping could be better	• Not much community activity • Difficult to review prs because of confusing ui • Quite buggy • Managed by enterprise Java company	• UI sucks • No fork

Distributed Version Control System

Snapshots, Not Differences - The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These other systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they store as a set of files and the changes made to each file over time (this is commonly described as delta-based version control).

Nearly Every Operation Is Local - Most operations in Git need only local files and resources to operate — generally no information is needed from another computer on your network. If you’re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous.

DVCS clients not only check out the latest snapshot of the directory but they also fully mirror the repository. If the server goes down, then the repository from any client can be copied back to the server to restore it. Every checkout is a full backup of the repository. Git does not rely on the central server and that is why you can perform many operations when you are offline. You can commit changes, create branches, view logs, and perform other operations when you are offline. You require network connection only to publish your changes and take the latest changes.

DVCS Terminologies
Local Repository
Every VCS tool provides a private workplace as a working copy. Developers make changes in their private workplace and after commit, these changes become a part of the repository. Git takes it one step further by providing them a private copy of the whole repository. Users can perform many operations with this repository such as add file, remove file, rename file, move file, commit changes, and many more.
Working Directory and Staging Area or Index
The working directory is the place where files are checked out. In other CVCS, developers generally make modifications and commit their changes directly to the repository. But Git uses a different strategy. Git doesn’t track each and every modified file. Whenever you do commit an operation, Git looks for the files present in the staging area. Only those files present in the staging area are considered for commit and not all the modified files.