Monthly Archives: March 2021

Chase scenes have been a staple in movies for almost as long as movies have existed. And boy have they changed over the years! Car chase scenes from the 1920s look practically comical now, yet were at the pinnacle of on-screen drama back in their day. With Fast & Furious 9 set to hit our screens this year, Insider decided to take a look at how theyve evolved over the last 100 years.

From 1924s Sherlock Junior, through Bullitt, The French Connection, Ronin, Drive and more, through to the latest Fast & Furious movies, it covers a lot of ground in not only how the filming of the scenes has evolved, but how new technological innovation has allowed them to kick things up a notch every so often.

Most of us wont be using tech and equipment anywhere near as advanced or as expensive as the examples illustrated in the video above, and I dont think most of us would be able to convince Lexus or Mercedes to send out a tech to disable the safety features of our vehicles to film a chase scene, but it is quite interesting to see where the technology is at and what it allows filmmakers to do these days.

Its also fantastic to see that even in the latest overplayed Hollywood franchises, the care chase sequences are still mostly shot practically and arent CG. At least, not the driving. A lot of them still use CG to extend the set and make a city look like a completely different city on the other side of the planet.

Whats your favourite movie chase scene?

[via ISO1200]

Read the rest here:

Watch to see the evolution of chase sequences over the last 100 years - DIYphotography

The deal will see Evolution provide its leading portfolio of online casino games, game show-style gaming and first person offering to PlayLive! customers in the state of Pennsylvania from Evolutions live studio in Philadelphia. Go live is planned during the second quarter of 2021.

Joe Billhimer, executive vice president at Cordish Gaming Group, said: Our Live! Casinos and Hotels set a new standard in best-in-class customer experiences with highly acclaimed gaming, hotel, dining and entertainment destinations throughout the Mid-Atlantic region.

"One of our main objectives in the development of the PlayLive! Online casino was to deliver a complementary online offering that is just as entertaining and attractive to our customers.

"We have selected Evolution as our strategic online partner because we are confident that the exceptional quality and breadth of the Evolution offering will enable us to achieve this goal.

Jeff Millar, commercial director, North America at Evolution, commented: We are excited and proud to be working with Cordish Gaming Group and PlayLive! Casino. The extensive Evolution online casino and entertainment portfolio is a great fit for further developing their Live! experience online.

See the original post:

Evolution deal with Cordish Gaming in Pennsylvania - InterGame

The ConversationMar 30, 2021 19:38:05 IST

Madagascar has many mini creatures. These include a recently discovered group of miniaturised frogs as well as the discovery earlier this year of the smallest reptile on earth the Brookesia nana, or nano-chameleon, which is the size of a paperclip. Moina Spooner, from The Conversation Africa, asked Dr Mark D Scherz, an amphibian and reptile specialist who focuses on Madagascar, to explain what causes these animals to miniaturise.

Madagascar is famous for its small animals; the mouse lemurs, the smallest primates on earth, for instance, are widely known. Theres also growing awareness that Madagascar is home to a variety of other uniquely miniaturised animals, especially chameleons and frogs. In those groups, researchers have discovered large numbers of tiny species in recent years.

In 2017, researchers described 26 species of Stumpffia a group of frogs the smallest of which is not even 1cm long at adult body size. It is one of the smallest frogs in the world.

Then, in 2019, my colleagues and I showed that several different groups of cophyline microhylids a group of narrow-mouthed frogs that are only found in Madagascar have become miniaturised independently. One group of these was an entirely new genus. We gave them the fitting name Mini, with the three speciesMini mum,Mini scule, andMini ature.

We have also found some new tiny chameleons. In 2019, we describedBrookesia tedi, a chameleon that reaches a total length of just 32mm. And then in early 2021, we describedBrookesia nana, the smallest chameleon, which has adult males of just 21.6mm total length, and females 28.9mm.

There are probably many different reasons why these animals have evolved to be so small. For instance, it might be possible for them to exploit new resources that werent previously available to them. This may be new food sources, or exploring the space between leaves and tree roots that is inaccessible to larger animals.

It could also be driven by competition with other, similar species. Species may diverge into different size categories to partition their resources and avoid direct competition.

In many cases, there may be no strong or single selective force that is driving the miniaturisation at all, but instead it could simply be a process of random change in the population, which occurs in all organisms over time. This is further driven by population bottlenecks as the smaller and smaller animals get cut off from other populations.

The simple answer is that we just dont know yet in any of the cases, and it is likely that in most it is a combination of factors. We are much better able to say what the correlates of miniaturisation are that is, the suite of features, behaviours, and ecologies that accompany miniaturisation than the causes.

Brookesia nana, described in 2019, is one of the smallest chameleons, and indeed one of the smallest amniote vertebrates, on earth. Image Credit: Frank Glaw/Mark D Scherz

Speaking only of reptiles and amphibians, maybe, but it is hard to say for sure. South-East Asia hasa massive diversity of miniaturised frogs, for instance, but whether the number of major miniaturisation events in that region is greater or less than in Madagascar is difficult to say for sure.

The same goes for Central and South America, where there are plenty of tiny amphibians and reptiles, including salamanders, frogs and lizards.

Ultimately, even though Madagascar may not be the world champion in terms of the number of miniaturised reptiles and amphibians, I think it does stand out as an exceptionally interesting place in which to study their evolution, and we are only just starting to scratch the surface of this.

This is the question I find the most exciting. From miniaturisation we can learn all kinds of interesting things about physiology, evolution and biomechanics how organisms move and function.

For instance, there appears to be a pattern where the evolution of miniaturisation is associated with changes in ecology. Almost all miniaturised frogs in Madagascar are terrestrial, irrespective of whether their ancestors were terrestrial arboreal (living in trees). The only conditions under which miniaturised frogs have remained arboreal throughout miniaturisation has been when they reproduce in the water cavities at the base of certain plants leaves, such as thePandanusplant.

We have also learned that the microhylid frogs of Madagascar have mostly miniaturised by retaining juvenile-like characteristics, known as paedomorphosis. For instance, they all have relatively large heads and eyes for their body sizes.

But one species,Rhombophryne proportionalis, has apparently miniaturised by proportional dwarfism. It has the approximate proportions of a non-miniaturised Rhombophryne. So, although paedomorphosis may be the typical way that Malagasy frogs miniaturise, it is by no means the only way that they can miniaturise.

Another particularly interesting finding is that miniaturisation has apparently evolved again and again in different lineages. This was already evident in frogs at the global scale (there are miniaturised frog lineages throughout the tropics). But one group of frogs in Madagascar has done this five or more times alone. This tells us that the evolution of miniaturisation can occur frequently and may be advantageous under certain circumstances.

From our work on miniaturised chameleons, we have also found that, as these lizards shrink, their genitals increase in relative size. We think that this is because the females are larger than the males. Because the male genitals must couple with those of the females for successful reproduction, and because the female is not as small as the male, the males genitals are constrained to remain proportional to the size of the female, even while his body size evolves to be smaller.

There are hundreds of open questions in the field of tiny vertebrate studies. We are just beginning to understand how widespread and common this trait is, how many species have done it, and how many miniaturised species remain undescribed. There is a whole miniature frontier of interesting research to be had among these tiny vertebrates, and I, for one, am excited to see what we discover next.

Mark D Scherz, Research scientist, Technical University Braunschweig

This article is republished from The Conversation under a Creative Commons license. Read the original article.

Read the original post:

What Madagascars tiny chameleons, frogs reveal about evolution of miniaturised animals - Firstpost

Over the years, the Indian retail sector has become one of the most dynamic and fast-growing industries that have progressed through several phases. According to the World Banks Doing Business report, India was ranked 63rd and is the worlds fifth-largest global destination in the retail space in the world. While retail was hit hard by the pandemic, the sectors revival process is well underway.

To elevate business growth and sales, and meet the ever-evolving consumer expectations, retailers are now leveraging cutting-edge technology to gather relevant information from the vast volumes of data available.

As the retail sector is on the cusp of a revolution, technology has been a fundamental element to the massive progress the retail sector has achieved over the years. To gain better insights, lets take a look at how the industry has evolved by leveraging novel technologies.

In India, the origins of retailing can be traced back to the emergence of mom-and-pop stores. Despite bigger franchises coming up later, mom-and-pop stores continue to remain a preferred source of shopping for customers, particularly for urgent requirements. It was only during the 1990s that the Indian retail market began to witness the emergence of large-scale franchises from big corporates.

Today, the retail market has a significant impact on the countrys economy. Over time, Indias retail sector has transcended from technology incorporation being a pipe dream to even Kirana stores leveraging leading-edge technology.

Just like other industries, technology has truly been a game-changer for Indian retail. Retailers today are trying to harness its power through AI, ML, Data Analytics, etc. A burgeoning millennial population, growing per capita incomes, and most importantly, increasing internet penetration are fueling the rise of the retail sector. Today, the entire retail sector, right from Kirana stores to large corporate franchises, has gone digital and is embracing the revolution to stay ahead in an increasingly competitive market.

For instance, in-store services, integrated payment gateways, 24x7 virtual assistance and order placement, same-day or next-day deliveries, real-time order tracking, warehouse automation, and inventory and supply chain optimisation have given a major boost to the industry.

As more and more players gravitate towards online retailing, with technology providing easy access, both the in-store and online shopping experience has transformed. From providing tablets or iPads, viewing products and their specifications to downloadable brochures and other online marketing, retailers are leaving no stone unturned to enhance the customer experience.

Indias retail sector has come a long way from offline, in-store shopping to providing tech-led services to enable a completely digital way of shopping. Even against the backdrop of a global pandemic, retailers have managed to reinvent their strategies and adopt a holistic approach. Amidst the paradigm shift in consumer behaviour and demand, the objective of retail is also evolving.

The aforementioned trends and technologies are expected to gain further traction in the future and Indias retail industry is set to become a dynamic realm as there are parallel growth and evolution of investments in infrastructure, modified approach, and consumer demands.

(Disclaimer: The views and opinions expressed in this article are those of the author and do not necessarily reflect the views of YourStory.)

Read more here:

Technological evolution in the retail sector: Past, present, and future - YourStory

Parking in Bend has evolved over the last fifteen years and for many residents, not in a good way. This article describes how Bends parking requirements have evolved in preparation for the upcoming April 21 City Council work session on parking.

The starting point is the 2006 re-write of the development code, which relied on encouraging on-street parking to reduce off-street parking. For example, restaurant parking requirements were reduced by 70% and medical offices by 57%.

Another reduction came with a smorgasbord of parking credits options that an applicant can use to further reduce their parking requirements by another 20%. For example, credits were allowed for providing lockers and showers or having a transit line within 660 feet.

In 2016-17, city staff advocated the right-size parking movement, which is based on gathering data on local parking demand to strike a balance between local parking supply and local parking demand. This movement was started by Donald Shoup, a professor at UCLA who documented a significant over-supply of parking in many metropolitan areas where transportation planners used suburban parking requirements in urban environments. The Downtown Bend, Galveston Avenue and citywide parking studies completed in 2017 all used the principles of right-size parking.

Meanwhile, the 2016 urban growth boundary expansion adopted lower parking requirements for mixed-use projects and in the Bend Central District. In 2019, the parking requirements in the Bend Central District were reduced even further.

In August 2019, the Oregon Legislature passed HB 2001 requiring middle housing in all areas where single-family housing is allowed. Plus, no city regulation could cause unreasonable cost or delay to middle housing. DLCD, the state agency tasked with providing technical assistance to communities, began a yearlong process to draft new state regulations. Parking requirements were a constant point of contention in the DLCDs committees drafting these proposed regulations. In the last DLCD committee meeting on Nov . 24, Bends Planning Division representative lobbied unsuccessfully to remove an option that would allow the community to continue to choose their parking requirements. On Dec . 9, the Land Conservation and Development Commission wisely adopted regulations that allowed three paths to compliance, which included the path allowing communities to choose their parking requirements.

Bend immediately began the process to bring Bends development code into compliance. An ad hoc committee has been meeting every two weeks, and parking requirements are a point of contention. In the initial meeting, staff claimed there was only two paths to compliance. When some members pointed out the existence of the third path (communitys choice), staff stonewalled any efforts to use this third path by claiming the proof required for the third path was too hard for staff to handle.

In committee meetings, urbanists argue that reducing or eliminating off-site parking requirements would remove barriers to affordable housing. Right-size advocates argue that reducing or eliminating off-street requirements will not achieve the benefits claimed by the urbanists and lead to burdening adjacent existing businesses and residents.

In February, Councilor Melanie Kebler requested and was granted a work session to consider the elimination of minimum off-street parking requirements for all new development. Urbanists argue that this new trend (social engineering by force) is necessary to shift the community to tall, mixed-used urban cores and more walkable neighborhoods.

In response, a group of neighborhood association land use chairs compiled months of research on this new trend and created doesparkingmatter.com to display both sides of the issue. A survey was sent to members of neighborhood associations to gauge members opinion. The survey is available to anyone at the website. The sponsors of the website support right-size parking requirements based on local data and a community dialogue. Urbanist believe off-street parking will still occur, but they want the community to trust developers to decide how much. The council needs to hear the communitys voice (one of councils new goals).

Mike Walker is a retired civil engineer who worked over 40 years in land development including the redevelopment and management of two multi-tenant properties in Bend.

More here:

Guest column: The evolution of Bend's parking | Opinion | bendbulletin.com - The Bulletin

The only political office I have ever been elected to was a seat on the Jefferson County Republican Executive Committee. My name was on the ballot and I got the most votes. (Out of the very few cast back then in the Republican primary.) I lived in Birmingham.

But that Republican party was nothing like it is today. The people I met were honestly interested in good government and putting forth candidates of integrity, conviction and who were trustworthy. They were not the wackos we see too much of today. No Ted Cruz, no Ron Johnson, no Marjorie Taylor Greene. They were not trying to divide people and make fear and hate the main message of their campaigns for office.

So what happened? Or did anything really?

In 1948, something called the States Rights Democratic Party came into being. It was most commonly known as the Dixiecrat party. Its followers were Democrats from the deep South who were upset that President Harry Truman ordered integration of the military in 1948 and was seen as friendly to civil rights issues of Black Americans.

This did not sit well with southerners who were staunch segregationists. So the Dixiecrats were born. Their presidential candidate was Senator Strom Thurmond of South Carolina, who became a Republican in 1964. As Black people got the right to vote and became politically involved, they flocked to the Democratic party.

White flight was not just about southern whites response to school integration, it was also about the growth of the Republican party throughout Dixie.

Peggy Wallace Kennedy has written a fascinating and courageous book, The Broken Road,about her famous father, George C. Wallace. She makes it clear that she saw little difference in the political stances of her father in the 1960s and those of Donald Trump in 2016.

Listen to her Daddys politics were more than just bombastic style. The establishment and other politicians viewed him as a demagogue. Nobody will buy what he is selling, they declared. Just take a look at him. Take him out of those Alabama backwoods and hell be finished. That was a mistake. And forty-four years later, disaffected voters responded similarly toTrump. They rebelled against the same intellectualism and paternalism that Daddy railed against.

Daddys strategy of articulating and mobilizing the grievances of the dispossessed would become one of the core strategies of the Trump campaign forty-four years later. It was the politics of rage and fear. It was resentment for no particular reason. It was a tent revival in the dead of summer, slapping mosquitoes and singing Amazing Grace while the preacher was fooling around out back.

Strom Thurmond got 78 percent of the vote in the Alabama 1948 general election. Republican Thomas Dewey only 19 percent. In 2020 Donald Trump got 62 percent of the vote compared to Bidens 37 percent.

So the case can certainly be made that the DNA of Alabama voters has not changed much since at least 1948 and the Republican party has morphed into the old Dixiecrat party. Given that the majority of Alabamians are descendants of Scots-Irish, this is understandable. In general, Scots-Irish who came to this country were fierce, violent and independent people. They set their own rules and dared anyone to try and change them.

Their pride overruled common sense and permitted them to cast votes that were hurtful to their own well-being.

Look at Strom Thurmond in 1948. Or better yet, look at Barry Goldwater in 1964. Goldwater was a U.S. Senator from Arizona known for his straight talk and fiery rhetoric. Just the kind of candidate that the Scots-Irish loved. A candidate without a snow balls chance in Hell, but boy he could stir a Southern heart. Just like Donald Trump could do.

Even though Goldwater lost to Lyndon Johnson in the general election by the largest margin in history, he got 69 percent of the Alabama vote. (Second only to Mississippi.) Goldwater only won six states. His Arizona home and Louisiana, Mississippi,

Alabama, Georgia and South Carolina. Alabama also elected five Republicans to the national House of Representatives in 1964..

While the Dixiecrat party was then ancient history, Goldwater showed us that the Republican Party was fertile ground for right wing believers. In fact, Goldwaters conservatism, initially rejected as radical, infused the Republican Party.

If you dont think so, then look at what just happened in Georgia where the Republican led legislature has passed new law about how elections should be conduced.. A law that makes it illegal to give someone waiting in line to vote a bottle of water. No doubt Strom Thurmond would be elated. And most of us have now seen the photo with the governor surrounded by six white male legislators as he signed the bill.

And just outside the governors closed door a Black female legislator was arrested and taken to jail for knocking on the door.

You got to give Trump credit for one thing. He figured out that the Dixiecrat/Republicans were a festering wound. All they needed was someone to come along and pull the scab off. He obliged.

Ultimately national Republicans will have to realize that water fountains in downtown Atlanta and Birmingham are no longer labeled, For whites only and support policy that appeals to a much broader spectrum of Americans than they do now. If not, then they are only marking time until the day they end up where the Dixiecrats did. On the outside looking in.

As to Alabama, the Dixiecrat/Republicans will probably be around for a long time, too often listening to the radical voices that tell them a long-ago world still exists and sending people to Washington who may have a votebut no influence.

See original here:

Opinion | From Dixiecrat until today. The evolution of the Republican Party - alreporter.com

Tweed peacoats, plaid dresses, corsets, and cutlasses found discarded in antique store basements have attracted a new group of buyers in 2021: Teenagers.

Aesthetics, a branch of philosophy that studies the nature and qualifications of beauty, taste, and art, has been given a whole new meaning in the last decade by Gen Z social media users. The contemporary understanding of the term has completely changed to now align with a collection of visuals that represent a broad array of concepts ranging from historical eras, locations, genres of fiction, music, and even pre-existing subcultures. The most prevalent of 2021 aesthetics can be narrowed down to two categories: Cottagecore, an aesthetic that romanticizes cottage life, and Dark Academia, a style that engages in the eerie visuals of early 20th-century academia. As these two aestheticsalong with many other similar aestheticsgain popularity in the online lives of young people, it becomes important to understand how they arose, what they are, and what their modern-day implications may be.

For starters, Tumblr might have a few answers. Created in 2007, Tumblr was the first image-oriented social media platform to go mainstream. Pinterest and Instagram, both launched in 2010, followed soon after. Unlike its other social media predecessors, the platform centered around users ability to create a distinct visual identity by curating their blog with an individualized colour scheme and font palette, along with the reblogging of content. Zoe Karkossa, U4 Science, has avidly tracked the development of Tumblr aesthetics since she started her blog in 2013.

Tumblr was the first platform to really capitalize on the use of visual images as symbols, Karkossa said. You had Flickr [before], but that was [] meant to be photos that you took. [On] Tumblr, you had the option of curating [] images that other people have taken.

Karkossa argues that Tumblr provided access to a huge database of pictures and GIFs, which made certain recurring images, products, and color schemes popular among users. Before the white, upper-middle class VSCO blogger aesthetic, there were basic bloggers who drank Starbucks, wore Uggs, and posted highly stylized inspirational quotes on Instagram. While older millennials were evolving from the Scene kids of MySpace into early 2010s Hipsters, younger millennials and Gen Z-ers were building off of the styles on these online platforms to curate their own visual identities.

Beyond curating moodboard blogs, Tumblr was ultimately a fan-centric space. Teens on 2012-2014 era Tumblr created fandoms surrounding YouTubers, bands, shows, and even authors. With so many people discussing the same contentwhether it was the Arctic Monkeys AM, Troye Sivan and Tyler Oakleys Boyfriend Tag video, or the unforgettable Mishapocalypsecertain fashion styles also gained popularity on the website, like galaxy leggings and flower crowns. In turn, the mainstream basic aesthetic contended with a newer, though no less homogenous, fandom aesthetic.

Carrie Rentschler, an associate professor at McGills Department of Art History & Communication Studies who studies aesthetics through the lens of social media activism, noted that social media users must be aware of how different websites provide different avenues of expression for their creators. An aesthetic develops when certain visuals can move between different platforms, adapting in accordance to the new websites.

There is a kind of [] revision process that aesthetics are going through as part of the creative process, Rentschler said. You have this corpus of material on social media and cross-platform movement of [] emerging aesthetics and [] conventions. [Content creators have] a way of doing things that is not directly agreed upon [but rather, they] have chosen to make similar decisions.

Whereas Tumblr provided anonymity through its reblogging functionallowing the creation of a visual identity to be developed sans ownershipInstagram shifted visual communication toward a form of individualized social signalling. Instagram users do not simply curate content, they create it. The images an individual posts on Instagramlike the Helvetica-filtered early 2010s circle of shoes photosignified, to some extent, the fashion that they subscribed to and the internet subculture they were a part of. Simultaneously, Pinterest users can curate their style by searching up images and creating boards. Not long after, Instagram pages with moodboards followed.

It should come as no surprise, then, that the aesthetics that originated on Tumblr and were popularized through Instagram have taken TikTok by storm. The significance of aesthetics, however, lies not in their existence, but in their unexpected mainstream appeal, global influence, and escapist nature.

No aesthetic is perhaps as escapist as Cottagecore, a theme that originated on Tumblr in 2017although arguably popularized by Marie Antoinetteand presents a romanticized version of rural life, complete with green-coated fields, airy dresses, flowers, woven baskets, self-subsistence, and frolics through mystical fields. While it is an undeniably beautiful and otherworldly aesthetic that has sprouted many offshoots of its own, Cottagecore also has complicated socio-political undertones. It upholds a conservatively traditional lifestyle, yet at the same time is championed by queer women who find sapphic appeal in a sustainable, unpreturbed, romantic pastoral life. Furthermore, it idolizes anti-capitalism in its pursuit of self-subsistence, but is inherently consumerist in its pursuit of a certain lifestyleit takes money to be able to buy an array of vintage dresses, curate a charcuterie board, and to even have the time to frolic in a field.

Even so, the Cottagecore aesthetic holds no malicious intent, and provides the viewer a flower-spotted escape from a complicated and stressful world. Taylor Swifts release of two Cottagecore-themed albums in 2020 has pushed the aesthetic into the mainstream.

On the other end of the optical and atmospheric spectrum is Dark Academia, a neoclassicist subset of the larger Academia aesthetic which focusses on a certain macabre, academically rigorous, elite university lifestyle, reminiscent of Donna Tartts The Secret History. Think studying in a coffee-stained sweater vest, hidden in the nook of a snowed-in library, while you pore over an ancient Greek text to the sound of Vivaldi far off in the distance.

Jesse Smith, U1 Arts and TikTok content creator, delves into the details of their preferred aesthetic: Dark Academia.

Whereas Cottagecore is Midsommarwithout the horror [], Dark Academia is very Dead Poets Society,Good Will Hunting,[and] to an extent, Harry Potter, Smith said. A lot of the aesthetic has the undertones of nefariousness. You want to create a secret society with your friends and hide murder. That is not actuallysomething you want to do, but thats the vibe youre going for.

What both of these aesthetics have in common is that they provide young people a form of unique self-expression and a way to elude a world filled with death, disease, racialized violence, and political turmoil. Smith argues that Dark Academia ultimately boils down to self-expression and a growing opposition to the conventions and practices of the fashion industry.

We have a lot more of an opportunity, and a willingness to not conform, Smith said. A lot of the movement towards aesthetics is against the fashion industry [because] aesthetics cant be mass produced in the quality people are looking for. Fashion aesthetics have moved the younger generations more towards thrifting and higher quality clothing [.] People care a lot more about how they feel in their clothing rather than how that clothing presents them to the world.

Maybe the emergence of these strange subcultures is for the best: Pushing against fast fashion, pursuing a unique sense of self-expression in lockdown, and looking for a fantastical form of escape are arguably some of the best things young people can be doing right now. When the world feels like it is on fire, there is nothing wrong with putting on a flowy dress, closing your eyes, and thinking of a life where a trickling stream, a bloom of lily flowers, and a homemade meal await you by a cottage on a hill. Maybe you will even find yourself along the way.

Read more from the original source:

Escapism, identity, and the evolution of TikTok aesthetics - McGill Tribune

Iconic and superb,the Volkswagen Transporter - in its camper van versions - has always been a symbol of freedom and adventure. Throughout the years, it has beenthe favorite mean of transport for the hippies, the best van for surfers from all over the world, and the first point of reference to all the outdoors enthusiasts.

There have always been several companies involved in convertingthe VW Transporter, like Westfalia - the first one in 1953 and probably the most productiveone -, Reimo or Dehler. Only recently, Volkswagen Californiahas begun operatingas an independent brand, producing their own factory-converted vans. Whatever the case, let'stake a look at the VW Camper Van's evolution.

Related:Volkswagen Teases Massive Camper Van- The California XXL

It all started in 1949, when a man called Ben Pon, a Dutch businessman involved in importing Volkswagen Beetles into the Netherlands, visited a VW factory in Wolfsburg, and sketched out an idea for a brand-new automobile. The VW engineers wouldbe inspired by his sketches to bring the first Bulli -Bus e Lieferwagen (van) -to life.

In 1953,Wesfalia introduced the Camping Box,a set of custom wooden furniture for the Combi (different from the Commercial Transporter).Starting with a large all-in-one unit that fits behind the cockpit, this piece of furniturehides all the mattresses and cushions that form the sofa bed. Also,a place for a basin or a stove, as well as drawers for storing kitchen accessories were included. Finally, a removable table is installed perpendicularly to form a dinette. The canvas mushroom pop-top roof was a cool optional, destined to grow bigger in time.

In 1968, Volkswagen had produced more than 1 million Transporters and released a newervan:although it looked pretty similar to the T1, the T2 was very different. It had a new engine, new suspension, and a stabilizing bar was added to the back.The firstdifference that you could spot, however, is that the split windscreen was replaced with a singular window panel, that is why the T2 has also been named Bay-Window, or simply Bay.

The T2 was upgraded in 1973 and friendly referred to as the late-bay, with previous models being labeled early-bay.The late-bay had a slightly different look, including different front lights, a squared bumper,improved brakes, and the option of a larger engine.Based on Combis whose roof was cut offfromthe factory, the evolution towards a biggerpop-top roof was then perfectly natural and quite simple to implement in the Westfalia factories.

In 1979VW began the production of theT3 van.The numerous Westfalia camper versions were heavily marketed by VW, and those were thefirst vans featuring hard-tops. The T3was also noted bya large number of camper conversionmanufacturers, that wouldwork on the basis of the VW T3, drawinginspiration from therise of the motorhomes in the 1980s.

Available in a pop-top and high-top version, the Volkswagen T3 Joker edition wascharacterized by an L-shaped sofa bed, with beige furniture and fancyfabrics. Also in its Syncro version - 4 wheels driving - the Joker wasjust one of the various editions available during the '80s, marking the T3 one of the most appreciated van by the European adventurers.

Famous for its squared and marked shape, these days the T3 is gaining popularity again, and of course, it's super Instagrammable. The arrival of water-cooled and diesel engines allowed it to engulf even greater distances.Larger than the previous T2, it offersmore storage space.The American versionwas calledVanagon by VWto highlight the van hadthe room of a van, but the driving experience of astation wagon.

Variations of the US Vanagon model included the Standard Vanagon, with vinyl seats and a spartan interior; the Vanagon L with optional fabric seats, chrome window frames, more exclusive interior panels, and an optional dashboard fan and the Vanagon GLthat featured a padded steering wheel and front armrests. TheWestfaliapop-top Vanagons campers were available in the Campmobile version, fully equipped for camping, and the Weekender, a more basic edition equipped for shorter vacations.

In its unique '90s look, this is the fourth-generation Transporter. What all T4s have in common is the modern driving concept, still valid today, with a bigger front-engine and front-wheel drive: this makes the VWT4 easier for inexperienced Bulli drivers.

Among the different models available, this is the T4 California Freedom: with itsfancy equipment, it marks the higher-end versionin the California range. Just to mention few features: 5 cylinders 150hp TDI engine, auxiliary heating, cruise control, navigation system. Basically everything you need for a comfortable camping experience.

Related:10 Camper Vans That Are Perfect For Social Distancing

The California T5 was introduced in 2003 in the Beach and Comfortline series. The Beach is more simply equipped and available at a lower basic price. A folding roof, in which a bed was optional.

The Comfortline gives you a kind of being-at-homefeelingwith several cupboards and storage compartments, a refrigerator, a two-burner stove, a sink, and a sofa bed. A table can be opened and combined with the rotating front seats to form a seating group for four people. A camping table is stored in the sliding door, which can be used outside the vehicle with the two camping chairs in the tailgate. Unlike its predecessor, the furniture is no longer made of MDF, but of aluminum finished with wood veneer.

Following the launch of the T6 Transporter, in 2015 a new version of the VW California was released to replace the older T5 version. Some changes applied to the revised van area restyled grille, redesigned headlamps, and wing mirrors. Three equipment levels in this lineup were available: the T6 Ocean, the T6 Coast, and the T6 Beach. Yes, even at VW theyknow how bad you need a vacation in a tropical spot.

The California Ocean features an electro-hydraulically elevating aluminum roof that sustains abed. The rear seating in the California Oceancan also easily turn into an additional bed, givingthe kids a place to sleep.

The latest version of our beloved VW Camper Van was released between 2019 and 2020. Thenew VW California 6.1,with its series of aesthetic, technological, and technical innovations,is the ultimateanswerfor travelers who require high-end comforts on long journeys.

A larger chrome grille in the front and LED lights are the main exterior changes. About the interior, everything turned to be electrically controlled and set: Digital Cockpit on the dashboard and a control panel above the head - a touchpad that will make you feel inside a space shuttle - that can control thepop-top, heating, level functions to see if youre parked ready for sleeping, alarm and the sunrise function which lights up the interior at a specific time in the morning to wake you up.

Related:Volkswagen Will Debut Upgraded T6.1 California Camper At Caravan Salon

With this electric prototype,Volkswagenprojects the Bulli, the iconic Volkswagen minibus, into the future. VW grants flexibleinteriorsto take advantage of the room available and to find the setting that best suits the customer's needs.

According to Volkswagen, the van will feature an AR head-up displaythat projects the navigation directly in front of the car, onto the road. And thanks to the augmented reality projection, the directional arrows will indicate exactly the path you need to follow. Will this be the solution forreaching your destination without taking your eyes off the road? We don't know. But we do know that we just can't stop taking our eyes off those VW Camper Vans.

Next:Surprising Facts About Volkswagen And Its Cars

Next 12 Most Realistic Car Tuning & Racing Games For Real Gearheads

Dave D'Alcamo is a writer based in the Italian Motor Valley, but probably he is currently typing from the couch of his van. Pathologically into classics and vans, he shares the devotion for engines with his dad.

See more here:

This Is The Evolution Of The VW Camper Van | HotCars - HotCars

Instagram was once a great social media platform specifically tailored for users to share photos of everyday life with friends and family. However, today, it has transformed into a free, revenue-generating app for users around the world. Not many people use this app to become rich and famous in the first place, which may have led to a decline in average users.

This is not to say that Instagram has to worry about the app failing or not generating enough revenue to sustain itself; but that the evolution of how one uses the app has drastically changed.

Many people may recall the rise in social media influencers and famous celebrities promoting supplements such as Flat Tummy Tea. This drastically changed how the app was used in starting to promote products; as users were making money on this free app, where this did not benefit the apps revenue.

The rise in promotions has prompted users to only show the best parts of their life, to dress the best and not be their authentic selves, creating a social media persona, as well as shifting a focus on how many followers you have, how many likes, and how your follower to following ratio should be, etc. The shift in focus lessens the relaxation of the app, causing users to not enjoy it as much.

This shift in usage led to the creation of having a fake Instagram or a Finsta, in which only users closest peers follow and they share more personal and behind-the-scenes photos, that you would not want on your Rinsta, aka a real Instagram. What is interesting is that you are actually real on the Finsta rather than on the Rinsta because you are only highlighting the absolute best images you want others to see?

Having these two accounts proves how social media has become an essential tool in personal brands. Users have the option to turn their pages into a business page, a blog or an outlet through which they can share their talents and local and world news. It has become an all-encompassing app that displays a lot of information that can be beneficial and harmful. This is because of how information is spread on the app; in which they now have regulations on in terms of the verification of the claims made by different accounts and users.

Although many people have lost the use for actively posting on their Rinsta, the app itself is essential because of how fast users can share information with followers. Throughout COVID-19 and the world slowly opening back up, this is a platform that a lot of people have access to and could potentially reach a multitude of people to share all kinds of information for the masses.

Read the original:

Instagram is dying: The fall and evolution of Instagram - Chargerbulletin

Key Takeaways

At the QCon in March, I gave a talk on the evolution of distributed systems with Kubernetes. First, I want to start with a question, what comes after microservices? I'm sure you all have an answer to that, and I have mine too. You'll find out at the end what I think that will be. To get there, I suggest we look at what are the needs of the distributed systems. And how those needs have been evolving over the years, starting with monolithic applications to Kubernetes and with more recent projects such as Dapr, Istio, Knative, and how they are changing the way we do distributed systems. We will try to make some predictions about the future.

To set a little more context on this talk, when I say distributed systems, what I have in mind is systems composed of multiple components, hundreds of those. These components can be stateful, stateless, or serverless. Moreover, these components can be created in different languages running on hybrid environments and developing open-source technologies, open standards, and interoperability. I'm sure you can make such systems using closed source software or create them on AWS and other places. For this talk specifically, I'm looking at the Kubernetes ecosystem and how you can create such a system on the Kubernetes platform.

Let's start with the needs of distributed systems. What I have in mind is we want to create an application or service and write some business logic. What else do we need from the platform from our runtime to build distributed systems? At the foundation, at the beginning is we want some lifecycle capabilities. When you write your application in any language, then we want to have the ability to package and deploy that application reliably, to do rollbacks, health checks. And be able to place the application on different nodes and do resource isolation, scaling, configuration management, and all of these things. These are the very first things you would need to create a distributed application.

The second pillar is around networking. Once we have an application, we want it to reliably connect to other services, whether within the cluster or in the outside world. We want to have abilities such as service discovery, load balancing. We want to do traffic shifting, whether for different release strategies or some other reasons. Then we want to have an ability to do resilient communication with other systems, whether that is through retries, timeouts, circuit breakers, of course. Have security in place, and get adequate monitoring, tracing, observability, and all that.

Once we have networking, the next thing is we want to have the ability to talk to different APIs and endpoints, i.e., resource bindings - to talk to other protocols and different data formats. Maybe even be able to transform from one data format to another one. I would also include here things such as light filtering, that is, when we subscribe to a topic, maybe we are interested only in certain events.

What do you think is the last category? It is state. When I say state and stateful abstractions, I'm not talking about the actual state management, such as what a database does or a file system. I'm talking more about developer abstractions that behind the scenes rely on the state. Probably, you need to have the ability to do workflow management. Maybe you want to manage long-running processes or do temporal scheduling or some cron jobs to run your service periodically. Perhaps you also want to do distributed caching, have idempotence, or be able to do rollbacks. All of these are developer-level primitives, but behind the scenes, they rely on having some state. You want to have these abstractions at your disposal to create sound distributed systems.

We will use this framework of distributed system primitives to evaluate how these have been changing on Kubernetes and other projects.

Suppose we start with the monolithic architectures and how we get those capabilities. In that case, the first thing is when I say monolith, and what I have in mind, in the context of distributed applications, is the ESB. ESBs are pretty powerful, and when we check our list of needs, we would say that ESBs had excellent support for all stateful abstractions.

With an ESB, you could do the orchestration of long-running processes, do distributed transactions, rollbacks, and idempotence. Furthermore, ESBs also provide outstanding resource binding capabilities and have hundreds of connectors, support transformation, orchestration, and even have networking capabilities. And lastly, an ESB can even do service discovery and load balancing.

It has all things around the resiliency of the networking connection so that it can do retries. Probably, because by nature, an ESB is not very distributed, it doesn't need very advanced networking and releases capabilities. Where ESB lacks is primarily lifecycle management. Because it's a single runtime, the first thing is you are limited to using a single language. That's typically the language that the actual runtime is created in, Java, or .NET, or something else. Then, because it's a single runtime, we cannot easily do declarative deployments or do an automatic placement. The deployments are pretty big, quite heavy, so it usually involves human interaction. And another difficulty with such a monolithic architecture is scaling: We cannot scale individual components.

Last but not least, around isolation, whether that's resource isolation or fault isolation. None of these can be done with monolithic architectures. From our needs' framework point of view, the ESB's monolithic architectures don't qualify.

Next, I suggest we look at cloud-native architectures and how those needs have been changing. If we look at a very high level, how those architectures have been changing, cloud-native probably started with the microservices movement. Microservices allow us to split a monolithic application by business domain. It turned out that containers and Kubernetes are actually a good platform for managing those microservices. Let's see some of the concrete features and capabilities that Kubernetes becomes particularly attractive for microservices.

In the very beginning, the ability to do health probes is what made Kubernetes popular. In practice, it means when you deploy your container in a pod, Kubernetes will check the health of your process. Typically, that process model is not good enough. You still may have a process that's up and running, but it's not healthy. That's why there is also the option of using readiness and liveness checks. Kubernetes will do a readiness check to decide when your application is ready to accept traffic during startup. It will do a liveness check to check the health of your service continuously. Before Kubernetes, this wasn't very popular, but today almost all languages, all frameworks, all runtimes have health checking capabilities where you can quickly start an endpoint.

The next thing that Kubernetes introduced is around the managed lifecycle of your application - what I mean is that you are no longer in control of when your service will start up and when it will shut down. You trust the platform to do that. Kubernetes can start up your application; it can shut it down, move it around on the different nodes. For that to work, you have to properly implement the events that the platform is telling you during startup and shutdown.

Another thing that Kubernetes made popular is around deployments and having those declaratively. That means you don't have to start the service anymore; check the logs whether it has started. You don't have to upgrade instances manually - Kubernetes with declarative deployments can do that for you. Depending on the strategy you chose, it can stop old instances and start new ones. Moreover, if something goes wrong, it can do a rollback.

Another thing is around declaring your resource demands. When you create a service, you containerize it. It is a good practice to tell the platform how much CPU and memory that service will require. Kubernetes uses that knowledge to find the best node for your workloads. Before Kubernetes, we had to manually place an instance to a node based on our criteria. Now we can guide Kubernetes with our preferences, and it will make the best decision for us.

Nowadays, on Kubernetes, you can do polyglot configuration management. You don't need in your application runtime anything to do configuration lookup. Kubernetes will make sure that the configurations end up on the same node where your workload is. The configurations are mapped as a volume or environment variable ready for your application to use.

It turns out those specific capabilities I just spoke about are also related. For example, if you want to do an automatic placement, you have to tell Kubernetes the resource requirements of your service. Then you have to tell it what deployment strategy to use. For the strategy to work correctly, your application has to implement the events coming from the environment. It has to implement health checks. Once you put all of these best practices in place and use all of these capabilities, your application becomes an excellent cloud-native citizen, and it's ready for automation on Kubernetes (this represents the foundational patterns for running workloads on Kubernetes). And lastly, there are other patterns around structuring the containers in a pod, configuration management, and behavior.

The next topic I want to cover briefly is around workloads. From the lifecycle point of view, we want to be able to run different workloads. We can do that on Kubernetes, too. Running Twelve-Factor Apps and stateless microservices is pretty straightforward. Kubernetes can do that. That's not the only workload you will have. Probably you will also have stateful workloads, and you can do that on Kubernetes using a stateful set.

Another workload you may have is a singleton. Maybe you want an instance of an app to be the only one instance of your app throughout the whole cluster - you want it to be a reliable singleton. When it fails, it should be started again. Hence, you can choose between stateful sets and replica sets depending on your needs and whether you want the singleton to have at least one or at most one semantic. Another workload you may have is around jobs and cron jobs - with Kubernetes, you can do those as well.

If we map all of these Kubernetes features to our needs, Kubernetes satisfies the life cycle needs. The list of requirements I usually create is primarily driven by what Kubernetes provides us today. These are expected capabilities from any platform, and what Kubernetes can do for your deployment is configuration management, resource isolation, and failure isolation. Furthermore, it supports different workloads except serverless on its own.

Then, if that's all Kubernetes gives for developers, how do we extend Kubernetes? And how can we make it give us more features? Therefore, I want to describe the two common ways that are used today.

The first thing is the concept of a pod, an abstraction used to deploy containers on nodes. Moreover, a pod gives us two sets of guarantees:

Depending on if you're using init containers or application containers, you get different guarantees. For example, init containers are run at the beginning; when a pod starts, it runs sequentially, one after another. They run only if the previous container has been completed successfully. They help implement workflow-like logic driven by containers.

Application containers, on the other hand, run in parallel. They run throughout the lifecycle of the pod, and this is the foundation for the sidecar pattern. A sidecar can run multiple containers that cooperate and jointly provide value to the user. That's one of the primary mechanisms we see nowadays for extending Kubernetes with additional capabilities.

To explain the following capability, I have to tell you how Kubernetes works internally briefly. It is based on the reconciliation loop. The idea of the reconciliation loop is to drive the desired state to the actual state. Within Kubernetes, many bits rely on that. For example, when you say I want two pod instances, this is the desired state of your system. There is a control loop that continually runs and checks if there are two instances of your pod. If two instances are not there, it will calculate the difference if there is one or more than two. It will make sure that there are two instances.

There are many examples of this. Some are replica sets or stateful sets. The resource definition maps to what the controller is, and there is a controller for each resource definition. This controller makes sure that the real world matches the desired one, and you can even write your own custom controller.

When running an application in a pod and you cannot load any configuration file changes at runtimes. However, you can write a custom controller that detects config map changes, restart your pod and application - and thus pick up the configuration changes.

It turns out that even though Kubernetes has a good collection of resources, that they are not enough for all the different needs you may have. Kubernetes introduced the concept of custom resource definitions. That means you can go and model your requirements and define an API that lives within Kubernetes. It lives next to other Kubernetes native resources. You can write your own controller in any language that understands your model. You can design a ConfigWatcher implemented in Java that describes what we explained earlier. That is what the operator pattern is, a controller that works with the custom resource definitions. Today, we see lots of operators coming up, and that's the second way for extending Kubernetes with additional capabilities.

Next, I want to briefly go over a few platforms built on top of Kubernetes, which heavily use sidecars and operators to give developers additional capabilities.

Lets start with the service mesh, and what is a service mesh?

We have two services, service A that wants to call service B, and it can be in any language. Consider that this is our application workload. A service mesh uses sidecar controllers and injects a proxy next to our service. You will end up with two containers in the pod. The proxy is a transparent one, and your application is completely unaware that there is a proxy - that is intercepting all incoming and outgoing traffic. Furthermore, the proxy also acts as a data firewall.

The collection of these service proxies represents your data plane and are small and stateless. To get all the state and configuration, they rely on the control plane. The control plane is the stateful part that keeps all the configurations, gathers metrics, takes decisions, and interacts with the data plane. Moreover, they are the right choice for different control planes and data planes. And as it turns out, we need one more component - an API gateway to get data into our cluster. Some service meshes have their own API gateway, and some use a third party. All of these components, if you look into those, provide the capabilities we need.

An API gateway is primarily focused on abstracting the implementation of our services. It hides the details and provides borderline capabilities. Service mesh does the opposite. In a way, it enhances the visibility and reliability within the services. Jointly, we can say that API gateway and service mesh provide all the networking needs. To get networking capabilities on top of Kubernetes, using just the services is not enough: You need some service mesh.

The next topic I like to discuss is Knative - a project started by Google a few years ago. It is a layer on top of Kubernetes that gives you serverless capabilities and has two main modules:

Just to give you a feel, what Knative Serving is? With Knative Serving, you define a service, but that is different from a Kubernetes service. This is a Knative service. Once you define a workload with a Knative service, you get a deployment but with serverless characteristics. You don't need to have an instance up and running. It can be started from zero when a request arrives. You get serverless capabilities; it can scale up rapidly and scale down to zero.

Knative Eventing gives us a fully declarative event management system. Let's assume we have some external systems we want to integrate with, some external event producers. At the bottom, we have our application in a container that has an HTTP endpoint. With Knative Eventing, we can start a broker, which can trigger a broker that Kafka maps, or it can be in memory or some cloud service. Furthermore, we can start importers that connect to the external system and import events into our broker. Those importers can be, for example, based on Apache Camel, which has hundreds of connectors.

Once we have our events going to the broker, then declaratively with the YAML file, we can subscribe our container to those events. In our container, we don't need any messaging clients - for example, a Kafka client. Our container would get events through HTTP POST using cloud events. This is a fully platform-managed messaging infrastructure. As a developer, you have to write your business code in a container and don't deal with any messaging logic.

From our needs' point of view, Knative satisfies a few of those. From a lifecycle point of view, it gives our workloads serverless capabilities, so the ability to scale to zero, and activate from zero and go up. From a networking point of view, if there is some overlap with the service mesh, Knative can also do traffic shifting. From a binding point of view, it has pretty good support for binding using Knative importers. It can give us Pub/Sub, or point-to-point interaction, or even some sequencing. It satisfies the needs in a few categories.

Another project using sidecars and operators is Dapr, which was started by Microsoft only a few months ago - and is rapidly getting popular. Moreover, version 1.0 is considered to be production-ready. It is a distributed systems toolkit as a sidecar - everything in Dapr is provided as a sidecar and has a set of what they call building blocks or a set of capabilities.

What are those capabilities? The first set of capabilities is around networking. Dapr can do service discovery and point-to-point integration between services. Similarly, it can also do the tracing, reliable communications, retries, and recovery to service mesh. The second set of capabilities is around resource binding:

Interestingly, Dapr also introduces the notion of state management. In addition to what Knative and service mesh gives you, Dapr also has abstraction on top of the state store. Furthermore, you can have key-value-based interaction with Dapr backed by a storage mechanism.

At a high level, the architecture is you have your application at the top, which can be in any language. You can use the client libraries provided by Dapr, but you don't have to. You can use the language features to do HTTP and gRPC called the sidecar. The difference to service mesh is that here the Dapr sidecar is not a transparent proxy. It is an explicit proxy that you have to call from your application and interact with over HTTP or gRPC. Depending on what capabilities you need, Dapr can talk to other systems, such as cloud services.

On Kubernetes, Dapr is deployed as a sidecar and can work outside of Kubernetes (it's not only Kubernetes). Furthermore, it also has an operator - and sidecars and operators are the primary extension mechanism. A few other components manage certificates, deal with actor-based modeling, and inject the sidecars. Your workload interacts with the sidecar and does all the magic to talk to other services, giving you some interoperability with different cloud providers. It also gives you additional distributed system capabilities.

If I were to sum up, what these projects are giving you, we could say that ESB is the early incarnation of distributed systems where we had the centralized control plane and data plane - yet it didn't scale well. There is still a centralized control plane with cloud-native, but the data plane is decentralized - and is highly scalable with sound isolation.

We always would need Kubernetes to do good lifecycle management, and on top of that, you would probably need one or more add-ons. You may need Istio to do advanced networking. You may use Knative to do serverless workloads or Dapr to do the integration. Those frameworks play nicely with Istio and Envoy. From a Dapr and Knative point of view, you probably have to pick one. Jointly, they are providing what we used to have on an ESB in a cloud-native way.

For the next part, I have made an opinionated list of a few projects where I think exciting developments are happening in these areas.

I want to start with the lifecycle. With Kubernetes, we can do a useful lifecycle of your application, which might not be enough for more complex lifecycle management. For example, you may have scenarios where the deployment primitive in Kubernetes is not enough for your application if you have a more complex stateful application.

In these scenarios, you can use the operator pattern. You can use an operator that does deployment and upgrade where it also backs up maybe the storage of your service to S3. Furthermore, you may also find out that the actual health checking mechanism in Kubernetes is not good enough. Suppose the liveness check and readiness check are not good enough. In that case, you can use an operator to do a more intelligent liveness and readiness check of your application, and based on that, perform recovery.

A third area would be auto-scaling and tuning. You can have an operator understanding your application better and do auto-tune on the platform. Today, there are primarily two frameworks for writing operators, the Kubebuilder from Kubernetes special interest group and the Operator SDK, which is part of the operator framework created by Red Hat. It has a few things:

The Operator SDK lets you write operators - an Operator Lifecycle Manager, about managing the operators lifecycle and OperatorHub, where you can publish your operator. You will see over 100 operators manage databases, message queues, and monitoring tools if you go there today. From lifecycle space, probably operators are the area where most active development is happening in the Kubernetes ecosystem.

Another project I picked is Envoy. The introduction of service mesh interfaces specification will make it easier for you to switch different service mesh implementations. There has been some consolidation on Istio architecture in the deployment. You don't have to deploy seven pods for the control plane; now, you can just deploy once. More interestingly is what's happening at the data plane in the Envoy project. We see that more and more Layer 7 protocols are added to Envoy.

Service mesh adds support for more protocols such as MongoDB, ZooKeeper, MySQL, Redis, and the most recent one is Kafka. I see that the Kafka community is now further improving their protocol to make it friendlier for service meshes. We can expect that there will be even more tight integration, more capabilities. Most likely, there will be some bridging capability. You can do an HTTP call locally from your application in your service, and the proxy will, behind the scene, use Kafka. You can do transformation and encryption outside of your application in a sidecar for the Kafka protocol.

Another exciting development has been the introduction of HTTP caching. Now Envoy can do HTTP caching. You don't have to use caching clients within your applications. All of that is done transparently in a sidecar. There are tap filters, so you can tap the traffic and get a copy of the traffic. Most recently, the introduction of WebAssembly, means if you want to write some custom filter for Envoy, you don't have to write it in C++ and compile the whole Envoy runtime. You can write your filter in WebAssembly, and deploy that at runtime. Most of these are still in progress. They are not there, indicating that the data plane and service mesh have no intention of stopping, just supporting HTTP and gRPC. They are interested in supporting more application-layer protocols to offer you more, to enable more use cases. Mostly, with the introduction of WebAssembly, you can now write your custom logic in the sidecar. That's fine as long as you're not putting there some business logic.

Apache Camel is a project for doing integrations, and it has lots of connectors to different systems using enterprise integration patterns. Camel version 3, for instance, is deeply integrated into Kubernetes and uses the same primitives we spoke about so far, such as operators.

You can write your integration logic in Camel in languages such as Java, JavaScript, or YAML. The latest version has introduced a Camel operator that runs in Kubernetes and understands your integration. When you write your Camel application, deploy it to a custom resource, the operator then knows how to build the container or find dependencies. Depending on the platform's capabilities, whether that's Kubernetes only, whether that's Kubernetes with Knative, it can decide what services to use and how to materialize your integration. There is quite a lot of intelligence going outside of your runtime - but into the operator - and all of that happens pretty fast. Why would I say it's a binding trend? Mainly because of the capabilities of Apache Camel with all the connectors it provides. The interesting point here is how it integrates deeply with Kubernetes.

Another project I like to discuss is Cloudstate and around state-related trends. And Cloudstate is a project by Lightbend and primarily focused on serverless and function-driven development. With their latest releases, they are integrating deeply with Kubernetes using sidecars and operators.

The idea is, when you write your function, all you have to do in your function is use gRPC to get state, to interact with state. The whole state management happens in a sidecar that is clustered with other sidecars. It enables you to do event sourcing, CQRS, key-value lookups, messaging.

From your application point of view, you are not aware of all these complexities. All you do is a call to a local sidecar, and the sidecar handles the complexity. It can use, behind the scenes, two different data sources. And it has all the stateful abstractions you would need as a developer.

So far, we have seen the current state of the art in the cloud-native ecosystem and some of the recent developments that are still in progress. How do we make sense of all that?

If you look at how microservice looks on Kubernetes, you will need to use some platform functionality. Moreover, you will need to use Kubernetes features for lifecycle management primarily. And then, most likely, transparently, your service will use some service mesh, something like an Envoy, to get enhanced networking capabilities, whether that's traffic routing, resilience, enhanced security, or even if it is for a monitoring purpose. On top of that, depending on your use case, you may need Dapr or Knative, depending on your workloads. All of these represent your out-of-process, additional capabilities. What's left to you is to write your business logic, not on top, but as a separate runtime. Most likely, future microservices will be this multi-runtime composed of multiple containers. Some of those are transparent, and some of those are very explicit that you use.

If I look a little bit deeper, how that might look like, you write your business logic in some high-level language. It doesn't matter what it is; it doesn't have to be Java only as you can use any other language and develop your custom logic in-house.

All the interactions of your business logic with the external world happen through the sidecar, integrating with the platform and does the lifecycle management. It does the networking abstractions for the external system and gives you advanced binding capabilities and state abstraction. The sidecar is something you don't develop. You get it off the shelf. You configure it with a little bit of YAML or JSON, and you use it. That means you can update sidecars easily because it's not embedded anymore into your runtime. It makes patching, updating easier. It enables polyglot runtime for our business logic.

That brings me to the original question, what comes after microservices?

If we see how the architectures have been evolving, application architectures at a very high level started with monolithic applications. Yet Microservices gives us the guiding principles on how to split a monolithic application into separate business domains. After that came serverless and Function-as-a-Service (FaaS), where we said we could split those further by operations, giving us extreme scaling - because we can scale each operation individually.

I would argue that maybe FaaS is not the best model - as functions are not the best model for implementing reasonably complex services where you want multiple operations to reside together when they have to interact with the same dataset. Probably, multi-runtime, I call it Mecha architecture, where you have your business logic in one container, and you have all the infrastructure-related concerns as a separate container. They jointly represent a multi-runtime microservice. Maybe that's a more suitable model because it has better properties.

You get all the benefits of microservice. You still have all your domain, all the bounded contexts in one place. You have all the infrastructure and distributed application needs in a separate container, and you combine them at runtime. Probably, the closest thing that's getting to that right now is Dapr. They are following that model. If you're only interested from a networking aspect, probably using Envoy is also getting close to this model.

Bilgin Ibryam is a product manager and a former architect at Red Hat, a committer, and a member of the Apache Software Foundation. He is an open-source evangelist, regular blogger, speaker, and author of Kubernetes Patterns and Camel Design Patterns books. Bilgins current work focuses on distributed systems, event-driven architecture, and repeatable cloud-native application development patterns and practices. Follow him @bibryam for future updates on similar topics.

Continue reading here:

The Evolution of Distributed Systems on Kubernetes - InfoQ.com