Integration specialist. Linux aficiando. Web tinkerer. BizTalk and .NET developer. Chief Propeller Head at StoneDonut, LLC.
6523 stories
·
1 follower

This Week in Numbers: DevOps Favor Microservices

1 Share

Every application does not need to be decomposed into microservices, but the conventional wisdom is that the practice is becoming widespread. DZone’s recent survey of 605 software professionals sheds light on the matter: Twenty-six percent of respondents use a microservices architecture for at least one production application. Another 27 percent use microservices in development, leaving 47 percent having no exposure to that type of architecture.

The data reminds us that many hot trends cool off after an initial surge in adoption. However, digging deeper the survey also shows that microservices adoption is dramatically higher among the types of people that read The New Stack. In fact, 55 percent of those running containers in production also use microservices architecture for a production application. The correlation between DevOps is even more dramatic, with 81 percent of those using microservices in production also following continuous delivery or DevOps practices.

Microservice adoption is likely to continue, especially as best practices continue to evolve. Yet, with many applications not worth the effort of refactoring the progress will likely be gradual.

As a side note, DevOps and continuous delivery are 80 percent more likely to be practiced by those using microservices in production:

Feature image by David Sonluna on Unsplash.

The post This Week in Numbers: DevOps Favor Microservices appeared first on The New Stack.

Read the whole story
sbanwart
7 hours ago
reply
Akron, OH
Share this story
Delete

F# Weekly #3, 2018 – F# Compiler Office Hours

1 Share

Welcome to F# Weekly,

A roundup of F# content from this past week:

News

Videos & Slides

Blogs

F# vNext

Open source projects

New Releases

That’s all for now. Have a great week.

Previous F# Weekly edition –#2, 2018Subscribe

 







Read the whole story
sbanwart
7 hours ago
reply
Akron, OH
Share this story
Delete

AutoRuns module compatible with PowerShell Core 6.0

>_
2 Shares

I’ve glad to announce that my AutoRuns module is compatible with PowerShell Core 6.0 🙂

  • What changed? What was fixed?
    • The Get-FileHash function taken on PowerShell 4.0 wasn’t compatible with PowerShell Core. I’ve included a test on $PSVersionTable to fix this shortcoming.
    • The Get-WmiObject cmdlet was removed and replaced with Get-CimInstance by this commit (I’ve added a function to retrieve WMI namespaces recursively. I’ve also added a function to look for WMI providers)
    • There were some issues with the ImagePath property calculated from the raw value. Issues 5, 6, 7, 8, 9 were fixed.
    • I’ve added a template to report issue that I copied from this location. You can now submit an issue more easily.
  • What’s next?
  • What else?
  • Enjoy! PowerShell rocks! 😎





Read the whole story
sbanwart
20 hours ago
reply
Akron, OH
alvinashcraft
1 day ago
reply
West Grove, PA
Share this story
Delete

React, Redux, and Redux Observables

2 Shares

Today I will conclude this series as we dive into the final bit of our example and feature the setup of one of my favorite ways to structure my data access layer.

Part 3: Redux Observables

One of the great things about Redux is how well it organizes your state and how easy it can be to follow state changes. The uni-directional flow works well for this, but where it falls flat is when it comes to asynchronous operations, namely calls to get and manipulate data from a backend server.

This is not a new problem. Sagas, Thunks, and other approaches have been made to solve this problem. I cannot say that Redux Observables are the best, but certainly I have finding more and more uses for Reactive approaches in the code I am writing so, I welcome the ability to use RxJS in Redux.

The first step in this process is to update Redux to support this approach. See, Redux expects an actual object to be returned from a reducer which is fine for state changes, but not realistic for async operations. We need to change the middleware to support other types being returned; for this we need custom middleware, which we get from the redux-observable NPM package.

Most of the setup work for the custom middleware happens in the configureStore method which we created during the Redux portion of this series. Here is a shot of the updated configureStore method

observable1

It is not at all unusual for this method, as your application grows in size and complexity to gain complexity as well. In this case, we have brought in the applyMiddleware method from redux.

We use this new method to apply the result of createEpicMiddleware which comes from the redux-observable package. The parameter to this call is a listing of our “epics”.

An epic is a new concept that redux-observable introduces. For reference, here is a look at the Redux flow with these Epics included.

observable2

I like to think of epics as “Observable aware Reducers” mainly because they sit at the same level and have a similar flow. That being said, I do not look at epics as devices for updating state in most cases, instead I look at them as more specialized aspects of the system. Here is an example of the epic I use to get a list of Todo items from my sample application:

observable3

What is happening here is actually straightforward, however the methods of RxJS can make things a bbit hard to understand at first. Essentially, our call above which passed in rootEpic allowed Redux to pass emitted actions into our Epics. You recall that, in Redux, every action is passed to every reducer; which is why every reducer must have an exist case. Using combineReducers we can mash all of these reducers into one giant one. Similarly the call above with rootEpic is doing the same thing.

Unlike Reducers however, Epics do not need to have an exit case defined. They can safely ignore an action if it does not pertain to it. In this case, we use switchMap to ensure the any pre-existing occurrences of the operation are cancelled to make way for the new. Full docs: https://www.learnrxjs.io/operators/transformation/switchmap.html

The rule here is that we always return the core object of RxJS: Observable. Observabbles are, in many ways, similar to Promises. However, one major difference is that Observables can be thought of as being alive and always listening where Promises exist for their operation alone. This difference enables Observables to very easily carry out advanced scenarios without adding a lot of of extra work.

For the above, if fetchItems was called more than once, only one call would ever be in play. This is important because, the Observable returned once the call does complete sends off an action to a Reducer to add the fetched items into state. As a general rule, on our teams we do not use Epics to carry out changes to state, though it is possible we find that having this separation makes things a bit easier.

To call into an epic, you simply raise the action as you would normally via the dispatcher.

observable4

Here we call loadItems in componentWillMount (essentially when the App loads). This will raise the FETCH action that caused things to happen.

A more advanced scenario

Ok, so now you have the general idea, let’s look at something a bit more complex: forkJoin (https://www.learnrxjs.io/operators/combination/forkjoin.html).

In our example, we allow the user to create new Todo items and update existing ones. When the user is ready they can hit our sync button which saves all of the changed data to the server. This is an obvious scenario where “we want to do a bunch of discrete things and then, when they are all done, we want to do a finishing action”. This sort of thing before Promises was absolutely brutal.

Since we are using Obbservables we can do this without Promises but we will use a similar structure. For us, forkJoin is analogous to Promise.all.

observable5

In this code we do some very basic filtering to find new and existing items which have changed. We want to call two separate endpoints for these two things. Another strategy would have been to send everything up and let the server figure it out; but that is less fun. And this is even easier to do in C#.

The important thing to understand is that our methods createItem and updateItem both return observables (they update the local state to reset dirty tracking flags and, for new items, hydrate the Id field to override the temp Id given).

Here we use mergeMap (https://www.learnrxjs.io/operators/transformation/mergemap.html) to allow the inner Observables to complete and update their state as that action is not important to the action of indicating the sync is complete. For reference, here is the code for createItem.

observable6

You can see that we use map (https://www.learnrxjs.io/operators/transformation/map.html) here which is crucial so the observable that is returned can work with forkJoin, we dont want to wait for any internal completion at this level.

So what will happen is when post is called, it will return an Observable and that is immediately returned (along with all others). Internally, when the call does complete it will return our action result; map will then wrap this in an observable.

Ok, so this inner observable will be striped out of the outer by mergeMap (along with all others) and will be added to an array of Observables within another one using concat, in addition to two others (syncComplete and snackbarItemUpdate).

So that is crazy complicated. Try to remember that the parameter passed into mergeMap is the array of completed observables (completed in the sense that the web call finished) which contain state changes that need to be applied in addition to actions which hide a busy indicator and show a snackbar.

This is all compressed into a single observable (via concat) and returned to the middleware. The middleware will then dispatch each internal (which it expects to resolve to an object) action. This will then be checked by other epics and your set of reducers. In our case, the actions will perform state changes before finally signalling to dismiss the busy indicator and show our snackbar.

I realize that my explanation there was probably very hard to follow, also I am no RxJS expert. However, it does enable some very cool scenarios out of the box, and I like it because I believe there many advantages offered over Promises.

Let’s bring it home

So that concludes the series. I am actually giving a presentation based on this material, most recently at Codemash in Sandusky. I really do believe that Observables offers some solid advantages over what I have seen of Thunks and Sagas bbut, as always, evaluate your needs first and foremost.

Here is the code for the full app used throughout this demo: https://gitlab.com/xximjasonxx/todo-app

Examine the various remote branches to see starting points that you can use to see how well you understand the setup for the various parts.

Cheers.















Read the whole story
sbanwart
20 hours ago
reply
Akron, OH
alvinashcraft
1 day ago
reply
West Grove, PA
Share this story
Delete

Top stories from the VSTS community – 2017.01.19

2 Shares
Here are top stories we found in our streams this week related to DevOps, VSTS, TFS and other interesting topics. TOP STORIES Improve Software Testing – Take The Driving Seat – Phil EdwardBefore you can begin to improve software testing in your organisation, you need to refresh yourself as to why testing is so important.... Read More
Read the whole story
sbanwart
20 hours ago
reply
Akron, OH
alvinashcraft
1 day ago
reply
West Grove, PA
Share this story
Delete

January 2018 VSTS Hosted Agent Image Updates

1 Share
The January 2018 updates are rolling out this week and should complete by the end of the day Friday January 19, 2018 GitHub Release #1801 Visual Studio 2017 on Windows Server 2016 Disabled IE Welcome Screen #41 Added .NET Core SDK to 2.1.4 Updated Node.js to 8.9.1 #14 Updated VisualStudio to 15.5.3 Added Visual Studio... Read More
Read the whole story
sbanwart
20 hours ago
reply
Akron, OH
Share this story
Delete
Next Page of Stories