Working with SOAP often gets tricky, and dealing with WSDL might be a huge contribution to the complexity of this task. Really, it could be the least expected thing to face when you are into a modern & fancy language like for example, Scala, that is well known for its reactiveness and asynchronous way of dealing with requests. In fact, many of the software developers that have made their way into industry quite recently, might not even know about SOAP and WSDL protocols, and get quickly annoyed or even enraged when first trying to connect to such a legacy service. So, should we deprecate this altogether in favour of modern technology stack, or maybe there is a less painful solution?

IaC (Infrastructure as Code) is a modern approach and I believe that infrastructure is code. It means that we should use the same philosophy for infrastructure as for software development. If we are talking that infrastructure is code, then we should reuse practices from development for infrastructure, i.e. unit testing, pair programming, code review. Please, keep in mind this idea while reading the article.

Russian Version

Installation

Across all of Microsoft, we are focusing on empowering developers to build better apps, faster. One way we are accomplishing that is by providing a range of products and services covering all stages of the software development lifecycle. This includes IDEs and DevOps tools, application and data platforms on the cloud, operating systems, Artificial Intelligence and IoT solutions, and more. All of these are centered around developers, both as individuals working in teams and organizations, and as members of developer communities.

GitHub is one of the largest developer communities, and for millions of developers around the world their GitHub identity has become a critical aspect of their digital life. Recognizing that, we’re excited to announce improvements that will help GitHub users get started more easily with our developer services, including Azure DevOps and Azure.

What is DevOps and Why is it important?

Reporting has been an important capability for Azure DevOps customers who rely on Analytics to make data driven decisions.

Today, we’re excited to announce that the following Analytics features listed below will be included in our Azure DevOps Services offering at no additional cost. Customers will start to see these changes rolled out to their accounts soon.

In this post we'd like to share an interesting way of dealing with configuration of a distributed system.
The configuration is represented directly in Scala language in a type safe manner. An example implementation is described in details. Various aspects of the proposal are discussed, including influence on the overall development process.

(на русском)

Discovering git vendor extension.

Cross-post from my medium blog: https://medium.com/opsops/git-vendor-295db4bcec3a

I would like to introduce the proper way to handle vendoring of git repositories.

What is is ‘vendoring’?

Vendoring is a way to integrate other’s work into your own. It’s the opposite of ‘linking’ against third-party library. Instead of having that library as a dependency, application uses this library as a part of own source code and keep that code ‘inside’ itself.

Normally, vendoring is done by language tooling: bundler, cargo, pip, etc. But sometimes you need to vendor something not covered by any existing toolset, or something multi-language, that it’s impossible to find the ‘core’ language tool for that.

The solution for this situation is vendoring on a git level. You have your own git repository (I call it ‘destination repo’), and you want to incorporate some other repository (I call it ‘source repo’) as a directory into your (destination repo).

The things you expect from a well-designed vendoring system (regardless of Git it is or not):

• Visibility. You want to know that some code is vendored, means it wasn’t written by committer.

I'd like to share my story about migration an application to Openshift. Also, as a result, I will compare some of the most popular solutions and tools for managing your application inside Openshift. It is the transcription of my presentation at kubernetes SPB meetup #3.

This article contains a brief squeeze from my own experience and that of my colleagues, with whom I had been fighting incidents day and night. And many incidents would never have occurred if all these microservices that we love so much were written at least a little more carefully.

Unfortunately, some programmers seriously believe that a Dockerfile with any team at all inside is a microservice in itself and can be deployed even now. Dockers are running — money are incoming. This approach turns into problems starting from performance degradation, inability to debug, service failures and ending in a nightmare called Data Inconsistency.

If you feel that the time has come to launch one more app in Kubernetes / ECS / whatever, then I have something to object to.