September 2016 - Seite 83 von 89 - Cloud Computing Köln

Court documents / Apple v. Samsung

For the first time in more than 100 years the Supreme Court will take on a design patent case pitting the world’s two largest phone manufacturers against each other, a major legal battle that both sides say will shape the future of consumer technology and alter incentives for designers and engineers to create new products.

Next month, the Supreme Court will hear arguments from Samsung and Apple over how much money Samsung should be forced to pay for infringing on several of the iPhone maker’s design patents. The design elements include the iPhone's rectangular face with rounded edges and bezel, and a home screen populated by a grid of icons. Stemming from a lawsuit that began in 2011, Samsung was ordered to hand over $548 million. A significant portion of that amount, $399 million, was derived from the total profits Samsung took in from the sale of patent-infringing phones. Samsung will try to convince the Supreme Court that it shouldn&039;t have to forfeit all of the profits it generated from its devices, since only some components of its phones were patented by Apple.

In its latest brief filed this week, the final written argument before the two parties appear before the Supreme Court in October, Samsung argued that a ruling in favor of Apple would inspire a new breed of patent troll. Samsung believes that it shouldn’t be forced to hand over all the profits from its infringing phones, but only a percentage. This reflects the fact that portions of the phone were patented by Apple, but other significant portions were Samsung’s. Otherwise, Samsung argues, a company that infringes on a tiny percentage of another firm’s product could unfairly be held liable for 100% of its profits.

By forcing companies who infringe on design patents to hand over all their profits, as opposed to just a portion of their earnings, litigation-hungry entities will be encouraged to target technology companies whose products encompass hundreds or thousands of complex parts. Samsung argued that Apple’s take on patent law “would open up new frontiers of litigation that would stifle the very innovation that the patent system seeks to encourage.”

Samsung isn’t alone in thinking so. In a brief backing the company, tech giants including Google, Facebook, Dell, and eBay argued that the rationale behind Apple’s stance was “out of step with modern technology.” By way of analogy, the tech companies said that a manufacturer of a smart TV could be required to pay its total profits in damages if the TV infringed on someone else’s design patent, even in a very insignificant way. Samsung offers a more striking hypothetical: A car manufacturer that copied someone&039;s design for a cup holder would be compelled to turn over its entire profit generated from the car.

Apple maintains that the design of the now iconic iPhone was crucial to its success, and that Samsung’s copycat infringement was not merely ornamental. Last month, more than 100 design professionals including Calvin Klein and Alexander Wang agreed with Apple, writing in a brief to the Supreme Court that design is not just one insignificant aspect of a product, but — in the minds of consumers — represents the product itself.

Apple insists that the lower court correctly interpreted the law by ordering Samsung to turn over its total profits. “Samsung’s arguments are addressed to the wrong branch of government,” Apple’s lawyers wrote, suggesting that its rival take the issue to Congress rather than seek a reinterpretation of the law by the high court.

David Opderbeck, a law professor at Seton Hall University, told BuzzFeed News that the Supreme Court will likely rule in one of three ways: The justices may decide that the infringement of a design patent should always lead to damages equaling the total profits of a product; that the damages should be limited to the specific components and not the entire product; or take a kind of dynamic middle ground, where each case must depend on the specific facts and damages would be determined by how important the design patents were to the total product.

“In this age when product design is so closely wedded to technology, how does patent law adjust?” Opderbeck said. “Giving a reward to an innovator but not allowing an innovator to dominate the whole technology just based on design?”

Samsung and Apple will argue in front of the Supreme Court on Oct. 11.

Quelle: <a href="Samsung Tells Supreme Court Apple May Inspire New Breed Of Patent Troll“>BuzzFeed

2. September 20162. September 2016

da Agency

Cloud Native Application Interfaces

Standard Interfaces (or, the Thirteenth Factor)–by Brian Grant and Craig Mcluckie, GoogleWhen you say we need ‘software standards’ in erudite company, you get some interesting looks. Most concede that software standards have been central to the success of the boldest and most successful projects out there (like the Internet). Most are also skeptical about how they apply to the innovative world we live in today. Our projects are executed in week increments, not years. Getting bogged down behind mega-software-corporation-driven standards practices would be the death knell in this fluid, highly competitive world.This isn’t about ‘those’ standards. The ones that emerge after years of deep consideration and negotiation that are eventually published by a body with a four-letter acronym for a name. This is about a different approach: finding what is working in the real world, and acting as a community to embrace it.Let’s go back to first principles. To describe Cloud Native in one word, we’d choose “automatable”.Most existing applications are not. Applications have many interfaces with their environment, whether with management infrastructure, shared services, or other applications. For us to remove the operator from patching, scaling, migrating an app from one environment to another, changing out dependencies, and handling of failure conditions, a set of well structured common interfaces is essential. It goes without saying that these interfaces must be designed for machines, not just humans. Machine-friendly interfaces allow automation systems to understand the systems under management, and create the loose coupling needed for applications to live in automated environments. As containerized infrastructure gets built there are a set of critical interfaces available to applications that go far beyond what is available to a single node today. The adoption of ‘serverless patterns’ (meaning ephemeral, event driven function execution) will further compound the need to make sense of running code in an environment that is completely decoupled from the node. The services needed will start with application configuration and extend to monitoring, logging, autoscaling and beyond. The set of capabilities will only grow as applications continue to adapt to be fuller citizens in a “cloud native” world.Exploring one example a little further, a number of service-discovery solutions have been developed but are often tied to a particular storage implementation, a particular programming language, a non-standard protocol, and/or are opinionated in some other way (e.g., dictating application naming structure). This makes them unsuitable for general-purpose use. While DNS has limitations (that will eventually need to be addressed), it’s at least a standard protocol with room for innovation in its implementation. This is demonstrated by CoreDNS and other cloud-native DNS implementations. When we look inside the systems at Google, we have been able to achieve very high levels of automation without formal interface definitions thanks to a largely homogeneous software and hardware environment. Adjacent systems can safely make assumptions about interfaces, and by providing a set of universally used libraries we can skirt the issue. A good example of this is our log format doesn’t need to be formally specified because the libraries that generate logs are maintained by the teams that maintain the logs processing systems. This means that we have been able to get by to date without something like fluentd (which is solving the problem in the community of interfacing with logging systems).Even though Google has managed to get by this way, it hurts us. One way is when we acquire a company. Porting their technology to run in our automation systems requires a spectacular amount of work. Doing that work while continuing to innovate is particularly tough. Even more significant though, there’s a lot of innovation happening in the open source world that isn’t easy for us to tap into. When new technology emerges, we would like to be able to experiment with it, adopt it piecemeal, and perhaps contribute back to it. When you run a vertically integrated, bespoke stack, that is a hard thing to do.The lack of standard interfaces leaves customers with three choices: Live with high operations cost (the status quo), and accept that your developers in many cases will spend the majority of their time dealing with the care and feeding of applications.Sign-up to be like Google (build your own everything, down to the concrete in the floor). Rely on a single, or a small collection of vendors to provide a complete solution and accept some degree of lock-in. Few in companies of any size (from enterprise to startup) find this appealing.It is our belief that an open community is more powerful and that customers benefit when there is competition at every layer of the stack. It should be possible to pull together a stack with best-of-breed capabilities at every level — logging, monitoring, orchestration, container runtime environment, block and file-system storage, SDN technology, etc. Standardizing interfaces (at least by convention) between the management system and applications is critical. One might consider the use of common conventions for interfaces as a thirteenth factor (expanding on the 12-factor methodology) in creating modern systems that work well in the cloud and at scale.Kubernetes and Cloud Native Computing Foundation (CNCF) represent a great opportunity to support the emergence of standard interfaces, and to support the emergence of a fully automated software world. We’d love to see this community embrace the ideal of promoting standard interfaces from working technology. The obvious first step is to identify the immediate set of critical interfaces, and establish working groups in CNCF to start assess what exists in this area as candidates, and to sponsor work to start developing standard interfaces that work across container formats, orchestrators, developer tools and the myriad other systems that are needed to deliver on the Cloud Native vision.–Brian Grant and Craig Mcluckie, Google
Quelle: kubernetes

2. September 20162. September 2016

da Agency

Manage your APIs with Google Cloud Endpoints

Posted by Dan Ciruli, Product Manager, Google Cloud Platform

Today we’re announcing the open beta release of the newest set of features and open source components in Google Cloud Endpoints, a distributed API management suite that lets you deploy, protect, monitor and manage APIs written in any language and running on Google Cloud Platform (GCP). We’re also releasing new versions of the Cloud Endpoints Frameworks for Java and Python that reduce latency, support custom domains and feature improved debugging.

One of the challenges we faced was building an API platform at Google with sufficient performance to handle the surge in microservices in addition to the scale of our web APIs. That led us to develop a server-side proxy that performs traditional API management functions itself. This avoids an additional network hop and in our testing delivers sub-millisecond latency — compared to tens to hundreds of milliseconds with traditional standalone proxies.

And now, we’re releasing that architecture to you. The Extensible Service Proxy (ESP) is a NGINX-based proxy designed to run in the server-local architecture. Designed to be deployed in a containerized environment or on its own, ESP integrates with Google Service Control to provide ultra-low latency monitoring, authorization checks, API key validation and many of the other features that Google uses to manage its own APIs. ESP is being developed in GitHub.

We’re also announcing support for the OpenAPI Specification. We’re a founding member of the Open API Initiative (OAI), and recognize the value of standardizing how REST APIs are described. Organizations that adopt the OpenAPI Specification benefit from OAI tooling, while developing their applications in the language and framework of their choice.

Google Cloud Endpoints featuresThe beta release of Google Cloud Endpoints includes the breadth of API management functionality that you need to manage your own APIs, whether they’re accessed from mobile apps, web apps or other services. Today, Cloud Endpoints allows users to monitor the status of critical APIs with usage, error and consumption charts. It logs API calls to Google Cloud Logging and trace information to Google Cloud Trace, and enables powerful analytics by integrating with Google BigQuery. Cloud Endpoints supports end-user authentication through built-in Google authentication and integrations to Auth0 and Firebase Authentication, and creates and validates API Keys to track usage by client.

(click to enlarge)

Cloud Endpoints is designed to allow developers to easily choose the language and framework they want for their backend. Based on the Open API Specification (formerly known as Swagger), Cloud Endpoints supports backends running on Google App Engine Standard or Flexible Environment, Google Compute Engine or Google Container Engine. In App Engine Standard or Flexible Environments, you can transparently add in proxy functionality with a one-line config change, or deploy a containerized version of the proxy on Kubernetes and Container Engine.

GCP customers are already super-charging their development with Cloud Endpoints. “Cloud Endpoints have allowed us to build and ship our APIs faster and more consistently than ever before,” said Braden Bassingthwaite, technical lead at Vendasta. “Not having to worry about authentication, performance and status monitoring has reduced the time and effort we need to build great APIs at Vendasta.”

Endpoints Framework for Java and PythonIn addition to the new API management features, we’re also announcing new versions of the Google Cloud Endpoints API frameworks for Java and Python that run on App Engine Standard Environment. The new versions of those frameworks feature reduced latency, an improved developer experience and support for custom domains. In addition, these new frameworks allow you to opt into the new API management features. To read more about the Endpoints Frameworks, check out the Java and Python documentation.

Try it outDuring the initial part of our beta period, the API management features in Cloud Endpoints will be offered at no charge. We will announce final pricing during the beta period.

APIs are an area of focus and investment for GCP. Be on the lookout for upcoming releases from the Endpoints team with support for more use cases and additional functionality, including integration with Identity and Access Management, rate limits and quotas, developer portals and more. Read the documentation to get the know the details. Try our walkthroughs for App Engine (Standard or Flexible Environment, Container Engine or Compute Engine) and join our Google Cloud Endpoints Google Group to send us your feedback.

Quelle: Google Cloud Platform

1. September 20161. September 2016

da Agency

What’s brewing in Visual Studio Team Services: September 2016 Digest

This post series will provide the latest updates and news for Visual Studio Team Services and will be a great way for Azure users to keep up-to-date with new features being released every three weeks. Visual Studio Team Services offers the best DevOps tooling to create an efficient continuous integration and release pipeline to Azure. With the rapidly expanding list of features in Team Services, teams can start to leverage it more efficiently for all areas of their Azure workflow, for apps written in any language and deployed to any OS.

New features released in August 2016

Fall is upon us but the sun is always shining for Team Services users. In August, users got treated with a host of exciting Team Services updates – a major redesign of social coding with Git (new pull requests UI, comments with markdown and emoji, auto complete pull requests), a new clone in Git Tower option, a host of build and CI enhancements and updates in Agile tools and testing.

New navigation – get around Team Services faster

A new Team Services navigation offers a more efficient way of browsing around the various hubs within Team Services, so you can get to where you want in fewer clicks than before

Using Team Services with Jenkins gets easier

With the new improvements in the Jenkins tasks in Team Services, it has become even easier to perform common scenarios such as:

Use Jenkins to validate your Team Services pull requests
Use Jenkins continuous integration for your Team Services Git repository
Use Jenkins to test or deploy your Team Services build
Download Jenkins build artifacts for use in a Team Services test, build, or release

Copying/uploading files to deploy to Linux gets simpler too!

Updates in Team Services now make it easier to copy files over SSH during CI and CD. The following guides are great pointers on enabling deployment to Linux from Team Services/TFS.

Deploy an Azure Red Hat Linux VM running Apache Tomcat.
Deploy an Azure Ubuntu Linux VM running Apache Tomcat.

If you prefer uploading files via FTP, the new FTP upload task will make it easier to do so as part of a build.

Track requirements quality right on the team Services Dashboard

It is now easier to link your automated tests to requirements and use Dashboard widgets to track the quality of each requirements you want to track.

Team Services build pool gets .NET Core agent and more

The hosted build pool has been updated with new Xamarin versions and a .NET Core agent.

New extensions for Team Services

See the extensions monthly roundup for a preview of Definition of Done, Personas and Product Vision extensions.

Inside Team Services – Summer Interns and Package Management

See what three awesome interns are doing to improve the Package management experience in Team Services.

Quelle: Azure

Today, Facebook is bringing live video sharing to Messenger via a new feature called “Instant Video.”

Open Messenger in iOS or Android, start a conversation with a friend and the app will offer you the option of adding live video to your chat.

The video starts without sound, but you can turn it on if you want.

You can also turn your Messenger Instant Video into a full blown video call. The person on the receiving end simply needs to hit the green video camera button.

Facebook isn&039;t the first company to debut this sort of live video sharing concept. It exists in other apps already, including Google&039;s Duo and Snapchat.

Here’s what it looks like in Google Duo.