Stitch is run entirely on AWS. All of our transactional databases are run with Amazon RDS, and we rely on Amazon S3 for data persistence in various stages of our pipeline. Our product integrates with Amazon Redshift as a data destination, and we also use Redshift as an internal data warehouse (powered by Stitch, of course).

The majority of our services run on stateless Amazon EC2 instances that are managed by AWS OpsWorks. We recently introduced Kubernetes into our infrastructure to run the scheduled jobs that execute Singer code to extract data from various sources. Although we tend to be wary of shiny new toys, Kubernetes has proven to be a good fit for this problem, and its stability, strong community and helpful tooling have made it easy for us to incorporate into our operations.

While we continue to be happy with Clojure for our internal services, we felt that its relatively narrow adoption could impede Singer's growth. We chose Python both because it is well suited to the task, and it seems to have reached critical mass among data engineers. All that being said, the Singer spec is language agnostic, and integrations and libraries have been developed in JavaScript, Go, and Clojure.

Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek). We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture. We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.

Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows). Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.

After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...

I've used .NET for many years, but only in recent years, after Microsoft introduced .NET Core, I've found a new love and excitement for the technology again. The main driver for us using .NET Core is not that it is cross platform compatible, open source or blazingly fast (which it is!), but the fact that we can use (what we consider) the best programming languages (mainly F# and C#) to carry out our jobs without sacrificing the other benefits.

Today we run most of our web infrastructure on .NET Core in Docker containers, deployed into a Kubernetes cluster which spans across multiple time zones in the Google Cloud and we couldn't be happier. Due to the portability of the .NET Core platform we are even able to develop many new services as serverless functions with F# which has become an absolute game changer.

How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

https://eng.uber.com/distributed-tracing/

(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

I use C# because it is incredibly clear and easy to use. The documentation is second to none, being a Microsoft product, and if you just want something that works without exploring a million frameworks and libraries you can pretty much start a C# website and have it running in an hour. C# is basically, in my opinion, a cleaner and easier to use Java. My experience is limited to web design, however. It might come down to personal opinion but I wouldn't even know where to start writing a java back end website but visual studio makes it very easy to write it in C#. If you are new to full stack development I can't recommend Visual Studio enough. It does, however, hide away a lot of abstraction that programmers much more clever than me use to make really interesting websites and server setups. C# will do everything you need to create any website you can imagine, though.

Before I end my rant about how much I love this language I'd like to reiterate how easy it is to figure out problems you encounter. I was stuck on how to store a path string in a database and found the solution by browsing the documentation for 2 minutes, which included examples. Every ASP element is clearly and wonderfully documented.

I adopted Clojure and ClojureScript because:

• it's 1 language, multiple platforms.
• Simple syntax.
• Designed to avoid unwanted side effects and bugs.
• Immutable data-structures.
• Compact code, very expressive.
• Source code is data.
• It has super-flexible macro.
• Has metadata.
• Interoperability with JavaScript, Java and C#.

I'm #Fullstack here and work with Vue.js, React and Node.js in some projects but also C# for other clients. Also started learning Python. And all this with just one tool!: #Vscode I have used Atom and Sublime Text in the past and they are very good too, but for me now is just vscode. I think the combination of vscode with the free available extensions that the community is creating makes a powerful tool and that's why vscode became the most popular IDE for software development. You can match it to your own needs in a couple of minutes. Did I mention you can style it your way? Amazing tool!

Secure Membership Web API backed by SQL Server. This is the backing API to store additional profile and complex membership metadata outside of an Azure AD B2C provider. The front-end using the Azure AD B2C to allow 3rd party trusted identity providers to authenticate. This API provides a way to add and manage more complex permission structures than can easily be maintained in Azure AD.

We have .Net developers and an Azure infrastructure environment using server-less functions, logic apps and SaaS where ever possible. For this service I opted to keep it as a classic WebAPI project and deployed to AppService.

• Trusted Authentication Provider: @AzureActiveDirectoryB2C
• Frameworks: .NET Core
• Language: C# , Microsoft SQL Server , JavaScript
• IDEs: Visual Studio Code , Visual Studio
• Libraries: jQuery @EntityFramework, @AutoMapper, @FeatureToggle , @Swashbuckle
• Database: @SqlAzure
• Source Control: Git
• Build and Release Pipelines: Azure DevOps
• Test tools: Postman , Newman
• Test framework: @nUnit, @moq
• Infrastructure: @AzureAppService, @AzureAPIManagement

I use C# because of the ease of designing user interfaces compared to Java. Using Visual Studio makes C# a breeze for prototyping and creating apps and I really appreciate how quickly I can turn an idea into reality. I was first introduced to C# in a special topics course and quickly started preferring it over Java. The similarities between the two made the switch easy while the added benefits C# offers made it very worth it.