da Agency

How To Build Planet Scale Mobile App in Minutes with Xamarin and DocumentDB

Most mobile apps need to store data in the cloud, and #Azure DocumentDB is an awesome cloud database for mobile apps. It has everything a mobile developer needs, a fully managed NoSQL database as a service that scales on demand, and can bring your data where your users go around the globe — completely transparently to your application. Today we are excited to announce Azure DocumentDB SDK for Xamarin mobile platform, enabling mobile apps to interact directly with DocumentDB, without a middle-tier.

Here is what mobile developers get out of the box with DocumentDB:

Rich queries over schemaless data. DocumentDB stores data as schemaless JSON documents in heterogeneous collections, and offers rich and fast queries without the need to worry about schema or indexes.
Fast. Guaranteed. It takes only few milliseconds to read and write documents with DocumentDB. Developers can specify the throughput they need and DocumentDB will honor it with 99.99% SLA.
Limitless Scale. Your DocumentDB collections will grow as your app grows. You can start with small data size and 100s requests per second and grow to arbitrarily large, 10s and 100s of millions requests per second throughput, and petabytes of data.
Globally Distributed. Your mobile app users are on the go, often across the world. DocumentDB is a globally distributed database, and with just one click on a map it will bring the data wherever your users are.
Built-in rich authorization. With DocumentDB you can easy to implement popular patterns like per-user data, or multi-user shared data without custom complex authorization code.
Geo-spatial queries. Many mobile apps offer geo-contextual experiences today. With the first class support for geo-spatial types DocumentDB makes these experiences very easy to accomplish.
Binary attachments. Your app data often includes binary blobs. Native support for attachments makes it easier to use DocumentDB as one-stop shop for your app data.

Let's build an app together!

Step #1. Get Started

It&039;s easy to get started with DocumentDB, just go to Azure portal, create a new DocumentDB account,  go to the Quickstart tab, and download a Xamarin Forms todo list sample, already connected to your DocumentDB account. 

Or if you have an existing Xamarin app, you can just add this DocumentDB NuGet package. Today we support Xamarin.IOS, Xamarin.Android, as well as Xamarin Forms shared libraries.

Step #2. Work with data

Your data records are stored in DocumentDB as schemaless JSON documents in heterogeneous collections. You can store documents with different structures in the same collection.

In your Xamarin projects you can use language integtated queries over schemaless data:

Step #3. Add Users

Like many get started samples, the DocumentDB sample you downloaded above authenticates to the service using master key hardcoded in the app&039;s code. This is of course not a good idea for an app you intend to run anywhere except your local emulator. If an attacker gets a hold of the master key, all the data across your DocumentDB account is compromised.

Instead we want our app to only have access to the records for the logged in user. DocumentDB allows developers to grant application read or read/write access to all documents in a collection, a set of documents, or a specific document, depending on the needs.

Here is for example, how to modify our todo list app into a multi-user todolist app, a complete version of the sample is available here: 

Add Login to your app, using Facebook, Active Directory or any other provider.
Create a DocumentDB UserItems collection with /userId as a partition key. Specifying partition key for your collection allows DocumentDB to scale infinitely as the number of our app users growth, while offering fast queries.
Add DocumentDB Resource Token Broker, a simple Web API that authenticates the users and issues short lived tokens to the logged in users with access only to the documents within the user&039;s partition. In this example we host Resource Token Broker in App Service.
Modify the app to authenticate to Resource Token Broker with Facebook and request the resource tokens for the logged in Facebook user, then access users data in the UserItems collection.  

This diagram illustrates the solution. We are investigating eliminating the need for Resource Token Broker by supporting OAuth in DocumentDB first class, please upvote this uservoice item if you think it&039;s a good idea!

Now if we want two users get access to the same todolist, we just add additional permissions to the access token in Resource Token Broker. You can find the complete sample here.

Step #4. Scale on demand.

DocumentDB is a managed database as a service. As your user base grows, you don&039;t need to worry about provisioning VMs or increasing cores. All you need to tell DocumentDB is how many operations per second (throughput) your app needs. You can specify the throughput via portal Scale tab using a measure of throughput called Request Units per second (RUs). For example, a read operation on a 1KB document requires 1 RU. You can also add alerts for "Throughput" metric to monitor the traffic growth and programmatically change the throughput as alerts fire.

  

Step #5. Go Planet Scale!

As your app gains popularity, you may acquire users accross the globe. Or may be you just don&039;t want to be caught of guard if a meteorite strkes the Azure data centers where you created your DocumentDB collection. Go to Azure portal, your DocumentDB account, and with a click on a map, make your data continuously replicate to any number of regions accross the world. This ensures your data is available whereever your users are, and you can add failover policies to be prepared for the rainy day.

We hope you find this blog and samples useful to take advantage of DocumentDB in your Xamarin application. Similar pattern can be used in Cordova apps using DocumentDB JavaScript SDK, as well as native iOS / Android apps using DocumentDB REST APIs.

As always, let us know how we are doing and what improvements you&039;d like to see going forward for DocumentDB through UserVoice, StackOverflow azure-documentdb, or Twitter @DocumentDB.
Quelle: Azure

da Agency

Six DevOps myths and the realities behind them

The post Six DevOps myths and the realities behind them appeared first on Mirantis | The Pure Play OpenStack Company.
At OpenStack Days Silicon Valley 2016, Puppet Founder and CEO Luke Kanies dispelled the six most common misconceptions he’s encountered that prevent organizations from adopting and benefiting from DevOps.

Over a five-year period, Puppet conducted market research of 25,000 people that shows the adoption of DevOps is critical to building a great software company. Unfortunately, however, many companies find that the costs of the cultural change are too high. The result is that these firms often fail to become great software companies — sometimes because even though they try to adopt the DevOps lifestyle, they do it in a such way that the change in a way doesn’t have enough real value because the changes don’t go deep enough.

You see, all companies are becoming software companies, Kanies explained, and surveys have shown that success requires optimization of end-to-end software production. Organizations that move past barriers to change and go from the old processes to the new way of using DevOps tools and practices will be able to make the people on their team happy, spend more time on creating value rather than on rework, and deliver software faster.

Key points in the 2016 State of DevOps Report survey show that high-performing teams deploy 200 times more frequently than average teams, with over #2,500 times shorter lead times, so the time between idea and production is minimal. Additionally, these teams see failure rates that are #3 times lower than their non-DevOps counterparts, and they recover 24 times faster. The five-year span of the survey has also shown that the distance between top performers and average performers is growing.

In other words, the cost of not adopting DevOps processes is also growing.

Despite these benefits, however, for every reason to adopt DevOps, there are plenty of myths and cultural obstacles that hold organizations back.
Myth #1: There&8217;s no direct value to DevOps
The first myth Kanies discussed is that there’s no direct customer or business value for adopting DevOps practices. After all, how much good does it do customers to have teams deploying 200 times more frequently?

Quite a lot, as it happens. DevOps allows faster delivery of more reliable products and optimizes processes, which results in developing software faster. That means responding to customer problems more quickly, as well as drastically slashing time to market for new ideas and products. This increased velocity means more value for your business.
Myth 2: There&8217;s no ROI for DevOps in the legacy world
The second myth, that there’s no return on investment in applying DevOps to legacy applications, is based on the idea that DevOps is only useful for new technology. The problem with this view, Kanies says, is that the majority of the world still runs in legacy environments, effectively ruling out most of the existing IT ecosystem.

There are really good reasons not to ignore this reality when planning your DevOps initiatives. The process of DevOps doesn’t have to be all-or-nothing; you can make small changes to your process and make a significant difference, removing manual steps, and slow, painful, and error-prone processes.

What&8217;s more, in many cases, you can’t predict where returns will be seen, so there’s value in working across the entire organization. Kanies points out that it makes no sense to only utilize DevOps for the new, shiny stuff that no one is really using yet and neglect the production applications that users care about &8212; thus leaving them operating slowly and poorly.
Myth 3: Only unicorns can wield DevOps
Myth number three is that DevOps only works with “unicorn” companies and not traditional enterprise. Traditional companies want assurances that DevOps solutions and benefits work for their very traditional needs, and not just for new, from-scratch companies.

Kanies points out that DevOps is the new normal, and no matter where organizations are in the maturity cycle, they need to be able to figure out how to optimize the entire end-to-end software production, in order to gain the benefits of DevOps: reduced time to market, lower mean time to recovery, and higher levels of employee engagement.
Myth #4: You don&8217;t have enough time or people
The fourth myth is that improvement via DevOps requires spare time and people the organization doesn’t have. Two concepts at the root of this myth are the realities that no matter what you do, software must be delivered faster and more often and that costs must be maintained or decreased, and organizations don’t see how to do this &8212; especially if they take time to retool to a new methodology.

But DevOps is about time reclamation. First, it automates many tasks that computers can accomplish faster and more reliably and an overworked IT engineer. That much is obvious.  

But there&8217;s a second, less obvious way that DevOps enables you to reclaim time and money. Studies have shown that on average, SREs, sysadmins, and so on get interrupted every fifteen minutes &8212; and that it takes about thirty minutes to fully recover from an interruption. This means many people have no time to spend hours on a single, hard problem because they constantly get interrupted. Recognizing this problem and removing the interruptions can free up time for more value-added activity and free up needed capacity in the organization.
Myth #5: DevOps doesn&8217;t fit with regulations and compliance
Myth number five comes from companies subject to regulation and compliance who believe this precludes adoption of DevOps. However, with better software, faster recovery, faster deployments, and lower error rates, you can automate compliance as well. Organizations can integrate all of the elements of software development with auditing, security, and compliance to deliver higher value, and in fact, if these aren’t all done at once, companies are more than likely to experience a failure of some sort.
Myth #6: You don&8217;t really need it
Kanies says he hasn’t heard the sixth myth often, but once in a while, a company concludes it doesn’t have any problems that adopting DevOps would fix. But DevOps is really about being good at getting better, moving faster, and eliminating the more frustrating parts of the work, he explains.

The benefits of adopting DevOps are clear from Kanies’ points and from the data presented by the survey. As he says, the choice is really about whether to invest in change or to let your competitors do it first. Because the top performers are pulling ahead faster and faster, Kanies says, and “organizations don’t have a lot of time to make a choice.”

You can hear the entire talk on the OpenStack Days Silicon Valley site.The post Six DevOps myths and the realities behind them appeared first on Mirantis | The Pure Play OpenStack Company.
Quelle: Mirantis