To:
`
`Subject:
`
`Sent:
`
`Sent As:
`
`Attachments:
`
`Panasonic Corporation of North America (ptodocket@arelaw.com)
`
`U.S. TRADEMARK APPLICATION NO. 87033317 - RESPONSIVE INFRASTRUCTURE - 55210/897
`
`8/26/2016 1:54:30 PM
`
`ECOM119@USPTO.GOV
`
`Attachment - 1
`Attachment - 2
`Attachment - 3
`Attachment - 4
`Attachment - 5
`Attachment - 6
`Attachment - 7
`Attachment - 8
`Attachment - 9
`Attachment - 10
`Attachment - 11
`Attachment - 12
`Attachment - 13
`Attachment - 14
`Attachment - 15
`Attachment - 16
`Attachment - 17
`Attachment - 18
`Attachment - 19
`Attachment - 20
`Attachment - 21
`Attachment - 22
`Attachment - 23
`Attachment - 24
`Attachment - 25
`Attachment - 26
`Attachment - 27
`Attachment - 28
`Attachment - 29
`Attachment - 30
`Attachment - 31
`Attachment - 32
`Attachment - 33
`
`UNITED STATES PATENT AND TRADEMARK OFFICE (USPTO)
`
`OFFICE ACTION (OFFICIAL LETTER) ABOUT APPLICANT’S TRADEMARK APPLICATION
`
`U.S. APPLICATION SERIAL NO.   87033317
`
`           
`
`MARK: RESPONSIVE INFRASTRUCTURE
`
`*87033317*
`
` 
` 
`

`

`CORRESPONDENT ADDRESS:
`  
`       HOLLY PEKOWSKY
`
`CLICK HERE TO RESPOND TO THIS LETTER:
`
`  
`
`       AMSTER ROTHSTEIN & EBENSTEIN LLP
`
`http://www.uspto.gov/trademarks/teas/response_forms.jsp
`
`         90 PARK AVENUE
`
`           21ST FLOOR
`
`    
`
`    NEW YORK, NY 10016
`
`VIEW YOUR APPLICATION FILE
`
`APPLICANT: Panasonic Corporation of North America
`
`  55210/897
`
`    
`CORRESPONDENT’S REFERENCE/DOCKET NO :       
`CORRESPONDENT E-MAIL ADDRESS:   
`
`   
`
`     ptodocket@arelaw.com
`
`OFFICE ACTION
`
`STRICT DEADLINE TO RESPOND TO THIS LETTER
`TO AVOID ABANDONMENT OF APPLICANT’S TRADEMARK APPLICATION, THE USPTO MUST RECEIVE APPLICANT’S
`COMPLETE RESPONSE TO THIS LETTER WITHIN 6 MONTHS OF THE ISSUE/MAILING DATE BELOW.
`
`ISSUE/MAILING DATE: 8/26/2016
`
`The referenced application has been reviewed by the assigned trademark examining attorney.  Applicant must respond timely and completely to
`the issue(s) below.  15 U.S.C. §1062(b); 37 C.F.R. §§2.62(a), 2.65(a); TMEP §§711, 718.03.
`
`SEARCH OF OFFICE’S DATABASE OF MARKS
`
`The trademark examining attorney has searched the Office’s database of registered and pending marks and has found no conflicting marks that
`would bar registration under Trademark Act Section 2(d).  TMEP §704.02; see 15 U.S.C. §1052(d).
`
`SECTION 2(e)(1) REFUSAL - MERELY DESCRIPTIVE
`
`Registration is refused because the applied-for mark merely describes a feature of applicant’s goods.  Trademark Act Section 2(e)(1), 15 U.S.C.
`§1052(e)(1); see TMEP §§1209.01(b), 1209.03 et seq.
`
`A mark is merely descriptive if it describes a quality, characteristic, function, feature, purpose, or use of an applicant’s goods.  TMEP
`§1209.01(b); see, e.g., In re TriVita, Inc., 783 F.3d 872, 874, 114 USPQ2d 1574, 1575 (Fed. Cir. 2015) (quoting In re Oppedahl & Larson LLP,
`373 F.3d 1171, 1173, 71 USPQ2d 1370, 1371 (Fed. Cir. 2004)); In re Steelbuilding.com, 415 F.3d 1293, 1297, 75 USPQ2d 1420, 1421 (Fed. Cir.
`
`2005) (citing Estate of P.D. Beckwith, Inc. v. Comm’r of Patents , 252 U.S. 538, 543 (1920)).  
`
`The applicant’s mark is “RESPONSIVE INFRASTRUCTURE” for “hardware and software for controlling street and building lights, video
`cameras, vehicle movement and back-up energy.”
`
`The applied for mark is merely descriptive of the identified goods because it immediately refers to a primary feature of applicant’s goods,
`namely, the hardware and software are the fundamental architecture of a system designed to react quickly or keenly to something.
`
`The dictionary definitions attached hereto support the supposition that applicant’s mark is using the terms in their ordinary understanding to
`describe the goods.  Additionally, attached hereto are websites indicating that other producers of software use these same terms to describe their
`products.
`
` 
` 
` 
` 
` 
` 
` 
` 
` 
` 
` 
` 
`

`

`For the reasons stated above, the proposed mark merely describes the main feature of applicant’s goods and registration on the Principal Register
`must be refused under Trademark Act Section 2(e)(1).
`
`Although applicant’s mark has been refused registration, applicant may respond to the refusal by submitting evidence and arguments in support
`of registration.
`
`RESPONSE OPTIONS
`
`Supplemental Register
`
`Although an amendment to the Supplemental Register would normally be an appropriate response to this refusal, such a response is not
`appropriate in the present case.  The instant application was filed under Trademark Act Section 1(b) and is not eligible for registration on the
`Supplemental Register until an acceptable amendment to allege use meeting the requirements of 37 C.F.R. §2.76 has been timely filed.  37 C.F.R.
`§2.47(d); TMEP §§816.02, 1102.03.
`
`If applicant files an acceptable allegation of use and also amends to the Supplemental Register, the effective filing date of the application will be
`the date on which applicant met the minimum filing requirements of 37 C.F.R. §2.76(c) for the amendment to allege use.  37 C.F.R. §2.75(b);
`TMEP §§816.02, 1102.03.  In addition, the undersigned trademark examining attorney will conduct a new search of the USPTO records for
`conflicting marks based on the later application filing date.  TMEP §§206.01, 1102.03.
`
`TEAS PLUS OR TEAS REDUCED FEE (TEAS RF) APPLICANTS – TO MAINTAIN LOWER FEE, ADDITIONAL
`REQUIREMENTS MUST BE MET, INCLUDING SUBMITTING DOCUMENTS ONLINE:  Applicants who filed their application
`online using the lower-fee TEAS Plus or TEAS RF application form must (1) file certain documents online using TEAS, including responses to
`Office actions (see TMEP §§819.02(b), 820.02(b) for a complete list of these documents); (2) maintain a valid e-mail correspondence address;
`and (3) agree to receive correspondence from the USPTO by e-mail throughout the prosecution of the application.  See 37 C.F.R. §§2.22(b),
`2.23(b); TMEP §§819, 820.  TEAS Plus or TEAS RF applicants who do not meet these requirements must submit an additional processing fee of
`$50 per international class of goods and/or services.  37 C.F.R. §§2.6(a)(1)(v), 2.22(c), 2.23(c); TMEP §§819.04, 820.04.  However, in certain
`situations, TEAS Plus or TEAS RF applicants may respond to an Office action by authorizing an examiner’s amendment by telephone without
`
`incurring this additional fee.    
`
`/Jill I. Prater/
`
`Jill I. Prater
`
`USPTO, Law Office 119
`
`Trademark Examining Attorney
`
`571-272-8257
`
`jill.prater1@uspto.gov
`
`TO RESPOND TO THIS LETTER:   Go to http://www.uspto.gov/trademarks/teas/response_forms.jsp.   Please wait 48-72 hours from the
`issue/mailing date before using the Trademark Electronic Application System (TEAS), to allow for necessary system updates of the application. 
`For technical assistance with online forms, e-mail TEAS@uspto.gov.  For questions about the Office action itself, please contact the assigned
`trademark examining attorney.  E-mail communications will not be accepted as responses to Office actions; therefore, do not respond to
`this Office action by e-mail.
`
`All informal e-mail communications relevant to this application will be placed in the official application record.
`
` 
` 
`  
` 
` 
` 
` 
` 
` 
` 
`

`

`WHO MUST SIGN THE RESPONSE:  It must be personally signed by an individual applicant or someone with legal authority to bind an
`applicant (i.e., a corporate officer, a general partner, all joint applicants).  If an applicant is represented by an attorney, the attorney must sign the
`
`response.  
`
`PERIODICALLY CHECK THE STATUS OF THE APPLICATION:   To ensure that applicant does not miss crucial deadlines or official
`notices, check the status of the application every three to four months using the Trademark Status and Document Retrieval (TSDR) system at
`http://tsdr.uspto.gov/.   Please keep a copy of the TSDR status screen.   If the status shows no change for more than six months, contact the
`Trademark Assistance Center by e-mail at TrademarkAssistanceCenter@uspto.gov or call 1-800-786-9199.   For more information on checking
`status, see http://www.uspto.gov/trademarks/process/status/.
`
`TO UPDATE CORRESPONDENCE/E-MAIL ADDRESS:  Use the TEAS form at http://www.uspto.gov/trademarks/teas/correspondence.jsp.
`
` 
` 
`  
`

`

`httpsflwebcache.ooooleusercontent.comfsearch?o=cache:xRDa chFv|J1https:Hcetus—solutionscomfproiect—tvpelre
`soonsive—infrastructure—that—is—readv—for—anvthinof+&cd=4&hl=en&ct=c|nk&ol=us
`08i‘26i'2016 01 :35:34 PM
`
`This is Geogle's cache efhtt
`
`Aug1?.2015 17'11’1]? GMT.
`The current page could have changed in the meantime. Learn more
`
`of. It is a snapshot efthe page as it appeared on
`
`View source
`Text-onlyr version
`Full version
`Tip To 'JLIICiii'y' find your search term on this page press Ctri+F or Ell-F {Mac} and use the fintl oar
`
`c e t u S s o l u ti 0 n S catflfidflijtion%hitfitid'risw Sitiisiisfiaeéder Case Studies
`
`Events
`
`Resource Hub
`
`Contac
`
`
`
`Agile Infrastructure
`
`Responsive infrastructure that is ready for anything.
`
`In today’s fast-paced environment, businesses need to respond instantly to changing demands or face the risk of being left behind. Businesses
`
`are turning to increasingly flexible and adaptive infirasmicture solutions that will withstand ever-changing demands in a way that traditional
`
`infrastructure — ofien rooted in a 3-5 year refresh cycle — won‘t. The expectation of IT is
`
`

`

`
`httpsflwebcache.ooooleuseroontent.comfsearch?q=cache1xRDa chFv|J1https:Hcetus—solutionscomfiproieot—tvpelre
`
`sponsive—infrastruoture—that—is—readv—for—anvthinof+&Cd=4&hl=en&ot=olnk&ol=us
`08f26f2016 01 :35:34 PM
`
`Follow us on Twitter
`
`Can’t find what you're looking
`for?
`
`My Tweets
`
`Recent Posts
`
`['5 Valle, Bil NdMWe Knowl...
`
`The Dog Deleied My Homewuk
`
`Cetuslamchnewwebsile
`
`Thesmrlcingsmari Park
`
`#Ciln'xParmeuLove is accelerafing the
`9M oflransfumafional rr soilions
`30055 the UK
`
`D1 51 B48 4315
`
`Copyright Cetus Solutions Limited
`
`[Zetus HI], Renown House, Merchants Quay, Salford Quays, Manchester, MEI] 333
`
`infoiéijl
`
`us-solutions.c:om
`
`

`

`httpsflwebcache . ooooleusercontent. comfsearch?q=cache : L6YNor9i5CYJ:httpsflwwwblueboxcloud . comiinsi ohtibloo—a
`rticlefresponsiye—infrastructure—with—opscode—chef—an—introduction+&cd=3&hl=en&ct=clnk&gl=us
`08f26i’2016 01:36:22 PM
`
`
`
`
`
`This is Goosle's cache Giotto ' whoelasticities-serialssiehtalhleoenmistressesa tinfrastriisturerir-rith-opsserteshe
`it appeared on Aug 9. 2015 23:35:43 GMT.
`The current page could have changed in the meantime. Learn more
`
`tori- It is a snapshot ofthe page as
`
`View source
`Text—only version
`Full version
`Tip: To quickly find your search term on this page. press Ctrl+F or aI-F {Mac} and use the find bar
`
`Responsive infrastructure with Opscode Chef— an introduction
`
`Published on June 04, 2013 ii Blue Box
`
`0 o 6 @ifyour application and its dependencies are growing too complex, Dpscode Chef can help you maintain
`
`your application's agility and responsiveness.
`
`Sam Cooper works as an Infrastructure Automation Engineer at Blue Box, specializing in Chef. He started working in the IT industry 12
`
`years ago and for the last two and a half has focused on using Chef to deliver infrastructure solutions. When not coding and learning
`
`he enjoys running, playing soccer, and rough housing with his 4 and 5 year old boys.
`
`Chef is an open source configuration managstrongent tool from Dpscode that lets you write code to manage the provisioning of your
`
`applications and infrastructure. With Chef you can move your servers from what may be a haphazard, sparsely defined provisioning process
`
`to one that is codified and easily repeatable. We are big fans of Chef here at Blue Box. We use it to deploy and maintain our cloud platform
`
`and to quickly provision customer deployments.
`
`Today's web application is more than a web server
`
`Apps have gone beyond a simple database backed web frontend. Today‘s application is typically a technology stack comprised of many
`different services such as:
`
`I nginxiApache
`
`I passengerfunicornlpmna
`
`I resgueisidekig
`I memcachediRedis
`
`I load balancerts)
`I AMQP
`
`I mysglir Postgres
`
`I monitoring [nagios sensu)
`
`Each service must be correctly configured, running, and in a healthy state for your application function property as a whole.
`
`It's only going to get more complex
`
`The proliferation of virtualization and the growth of the cloud make it much easier to build up rich application topologies. Services like Redis,
`
`AMQP, Hadoop, and Zookeeper are part of the growing grab bag of solutions you can assemble when constructing your application. While
`
`this should remove compiexity and add functionality to your application, it does add to the management burden of your application’s
`:_:__ _L—.._l.._— n__ ..._..I_ ____ IL;_ I...__l__ L. I- ___.._ IL- '._:__ _._.._;...__ _.___:r.__I'.___ ___l '.__l_.._.l:___ :_I_ ___l-
`
`

`

`httpsflwebcache . ooooleusercontent. comfsearch?q=cache : L6YNQr915CYJ:httpsflvvvvwblueboxcloud . comlinsi ohUbloo—a
`rtiClairesponsive—infrastructure—with—opscode—Chef—an—introduction+&Cd=3&h|=en&otzclnk&g|=us
`08f26f2016 01:36:22 PM
`
`infrastructure. One way to ease this burden is to movethe infrastructure specifications and instructions into code.
`
`Infrastructure as Code
`
`Traditionally, only the application layer has been captured in source control. With Chef, your infrastructure code will also live there. This is a
`transformalive change, enabling.
`
`Code reuse
`
`Reuse both your own organization's code and community code. There is most likely a cookbook that already exists for whatever you are
`
`trying to accomplish.
`
`Documentation
`
`Examine the node's run_list to find out which services and configurations are on a sewer.
`
`Consistency
`You will have a very high degree of confidence that your nodes will be the same.
`
`Elasticity and Repeatability
`
`Spinning up an extra Hadoop server becomes trivial once you've captured its configuration in Chef.
`
`Orchestration
`
`Let the nodes configure themselves based on the attributes of their peers. For example, if your web application talks to an AMQP sewer, the
`
`web server recipe can discover the IP address of that node and write it into its config. Ifyou ever lose your AMQP server, just bring tp a new
`
`one, and run chef—client on both nodes.
`
`Source control best practices
`
`Leverage source control to manage change {Pull Requests, Peer Reviews, Branching, etc.)
`
`Chef Server vs. Chef Solo
`
`There are two ways to run Chef, either with a Chef server using a Chef client or standalone using Chef Solo. Both allow you to use Chef to
`
`configure your infrastructure and capture it in code. Chef server gives you centralized managstrongent and orchestration capabilities you
`
`don‘t have with Chef Solo. Ifyou need dynamic provisioningthat can respond to the environment and perform service discovery, then Chef
`
`Server will be required.
`
`Chef Solo does not olfer a centralized management point {other than the source control repository where you keep your chef code), but it is
`
`great at doing initial server setups and adding documentation and repeatability to your infrastructure. For many use cases, Chef Solo is more
`
`than adequate.
`
`Ifyou are just starting out with Chef server, there are a couple good optiors:
`
`1. Use Opscode's Hosted Chef. This SaaS offering provides everything you need to use Chef server. You can create an organization
`
`and manage Lp to five nodes for free.
`Install your own open source Chef Server. With Chef 1 1, the task ofbringing up your own open source Chef Server is a simple two
`
`2.
`
`step process. The primary limitation of open source Chef is it allows only one name space for your Chef objects. This basically
`
`means there can only be one organization using it.
`
`Getting Started
`
`Opscode has a great tutorial site to help you get started with Chef. This will walk you through:
`
`I Cloning a termlate chef repository
`
`- Setting Lp your workstation (installing chef and configuring keys)
`- f‘rnrxtim ran rarrnnnl .ui-lh l—lnr-lnd Phnl'
`
`

`

`http31ttweboaohe.ooooleuseroontent.oomfsearoh?q=oaohe:LBYNorQISCYJ:httpsflvvvvwblueboxoloud.oomtinsiohtfibloo—a
`rtiolel’responsive—infrastructure—with—opsoode—ohef—an—introduotion+&od=3&h|=en&ot=olnk&g|=us
`08f26f2016 01:36:22 PM
`I Creating an account with Hosted Chef
`
`I Setting in a local vi finalized sewer via VirtualBox and Vagrant that you will manage with chef
`
`Conclusion
`
`Once you have captured your application's infrastructure in Chef, your application and its dependencies will be much more agile. You will no
`longer be handcuffed to your sewer instances and can easily recreate and manage your envirorment via your Chef code. Stay tuned fora
`
`post on howto spin up Chef nodes on your Blue Box cloud using Knife Bluebox.
`
`Happy Cheflng!
`
`DDSCDUB Ch 81'
`
`open SDUI'CE
`
`CHE! SEWEF
`
`{BSDUICBS
`
`CDUB
`
`SI'IIDDBIS
`
`SHARE
`
`LATEST POSTS
`
`I The Zombie Apocalypse and Other Cloud infrastructure Concerns
`
`I EuroPython 2016: Pythonic Epicenter in the Heart of Basque Country
`
`I The IBM internal GitHulJ Enterprise system Running on Blue Box
`
`I UpenStack East: Aug 23 & 24
`
`I Getting Started with Kubernetes on IBM Blue Box
`
`I Cloud Matters: The Right Fit for Hybrid Cloud
`
`I Load Balancing as a Service on IBM Blue Box
`
`I Delivering HIPAA on IBM Blue Box Local
`
`I M—mmmy tvlitaka
`
`I UpenStack Silicon Valley: August 9 & 10
`
`CATEGORlES
`
`I Blue Box General
`
`I Event
`
`I Partnerships
`
`

`

`
`httpsflwebcache . Goooleusercontent. comfsearch?q=cache : L6YNQr915CYJ:httpsflwwwblueboxcloud . comlinsi ohUbIOG—a
`
`rTiClefresponsive—infrastructure—with—opscode—Chef—an—introduction+&Cd=3&h|=en&otzclnk&g|=us
`...._......._,_.._,
`08f26f2016_01_:§_§:22 PM
`
`I Resource
`
`ARCHIVES
`
`I Augusl,201fi
`
`I Juiy,2016
`
`I June,2016
`
`I May,2016
`
`I Aprti,2016
`
`I March,2016
`
`I February, 2016
`
`I January,2016
`
`I December, 2015
`
`I November, 2015
`
`I October, 2015
`
`I Sentember,2015
`
`I Augusl,2{]15
`
`I Juiy,2015
`
`I June,2015
`
`I Maj-315
`
`I April,2015
`
`I March, 201::
`
`I Februaw, 2015
`
`I January,2015
`
`I December, 2014
`
`I November, 2014
`
`I October, 2014
`
`I September, 2014
`
`

`

`
`httpsflwebcaehe . Gooeleusereontent. comfseerch?q=caehe : L6YNQr915CYJ:httpsflwwwblueboxeloud . eomlinsi ohUbIOG—e
`
`rtiClefresponsive—ihirestructure—with—opseode—Chef—en—introduetion+&Cd=3&h|=eh&etzelnk&g|=us
`08f26f2016 01:36:22 PM
`
`0
`
`Rumor has it this cloud thing is taking off.
`
`Have you read the news?
`
`OUR STORY
`
`I About. \Je
`
`I Leadership
`I Caree rs
`
`RESOURCES
`
`I Case Studies
`
`I Videos:
`I flarafiheem
`
`I News
`
`I Events
`
`:- 2-315 Elue Bax Gretna All Rights Reeve-ruse.
`
`
`
`Contact ! Legal ! Privacy Felix?)r | ‘.-'-.I’ebs:-:e Terms
`
`'61 TRUSTe r
`Certified Ptlvacy
`
`

`

`
`http :ffwebcache.qoooleusercontent. comlsearch?q=cache:XiOwiALnN1WJ : bloobuosnao . comlresponsive—i nfrastructure—w
`
`ith—autoscalinq+&cd=6&hl=en&ct=c|ni<&ol=us
`08£26f2016 0113615? PM
`
` This is Google‘s cache of?!)
`The current page could have changed in the meantime. Leam more
`
`i335}; It is a snapshot of the page as it appeared on Aug 24, 2016 20:23:03 GMT.
`
`View source
`Text-only.r version
`Full version
`Tip: To quickly fino‘ your search term on this page. press Ctrl+F or l-F {Mac} and use the find bar.
`
`m bug snag
`
`i‘:?:i1.".'.i':13
`
`1:21-31:12
`
`:‘uocs
`
`lilo-.1
`
`c.=_=.i.‘9'.' 1'15: c
`
`Responsive infrastructure with
`Auto Scaling
`
`Maintaining high availability and performance is universally important, but at Bugsnag: we take
`
`extra care because its our job to alert product teams when things break in their services. We
`
`process up to half a billion error events a day, so reliability is huge to us and we have zero
`tolerance for downtime in our backend.
`
`Another challenge we face is the bighiy uncertain nature of our load. We can’t predict what it’El
`
`look like because it’s dependent on code deployed by our customers. but we need to be able to
`
`cope with all future increases. At the same time, we also want to keep our costs reasonable.
`
`With these responsibilities in mind, we’ve constructed an infrastructure that is flexible but
`
`resilient in the face of constantly changing load patterns. Using A'x‘i'S Auto cInc-sling, we’ve been
`
`able to maintain the highest levels of availability.
`
`Common Load Patterns
`
`To understand where and how Auto Scaling can be helpful, let‘s take a look at some common
`
`load patterns in applications.
`
`Fast Growth
`
`Fast growth is growth at an increasing rate overtime. This is often what we expect and hope for
`
`when we first launch a new product or service.
`
`Seasonal
`
`Seasonal load is characterized by cyclical periods of high load followed by lower load. Netflix is
`
`a great example of this, where their heaviest load is always in the evenings followed by typically
`
`

`

`http :ffweboaohe.ooooleuseroontent. oomlsearoh?q=oaohe:XIOWIALHN1WJ : bloobuosnao . oomlresponsive—i nfrastruoture—w
`ith—autosoalino+&od=6&hl=en&ot=olnk&o|=us
`0896:0016 0113615? PM
`
`low load in the mornings.
`
`Spiky
`
`Spiky load is generally the hardest load pattern to predict. and is characterized by acute periods
`
`of increased load. Spiky load presents unique architectural challenges because you‘ll need to
`
`figure out how to prepare for those unpredictable spikes.
`
`On or Off
`
`On and ofi load are things like scheduled jobs or daily report generation “here at times there
`
`isn’t any load at alt.
`
`common load patterns
`
`Most services don’t fit neatlyr into one of these specific categories — they may transition
`
`between different load patterns. or display characteristics of multiple at the same time.
`
`Bugsnag‘s load. for example. looks like fast growth (because we’re steadin adding customers
`
`over time). seasonal (because our load is heavy during the workweek and lower during the
`
`weekend)= and also spiky (because sometimes we experience large increases at unexpected
`
`times).
`
`In a world without Auto Scaling, the challenge then would be to figure out how to handle future
`load for each of these scenarios.
`
`

`

`
`http :ffwebeaehe.ooooleusercontent. eomlseareh?q=eaehe:XIOWIALHN1WJ : bloobuosnao . eomlresoonsive—i nfrastructure—w
`
`ith—autosoalino+&cd=6&hl=en&ct=clnk&olzus
`0896:0016 0113615? PM
`
`
`
`Ideally. your strategy would allocate enough resources for expected high load points. keeping in
`
`mind your tolerance level for being underprovisioned. Unfortunately, this approach can actually
`
`end up being very costly because most of the time you’ll be paying for computing resources that
`
`aren't in use. In the worst case, you might fmd yourself in a situation where you’re
`
`underprovisioned and unable to keep up with the demand of your users.
`
`Auto Scaling is helping us solve this.
`
`What is Auto Scaling?
`
`Auto Scaling is a robust approach to backend infrastructure that attempts to scale up resources
`
`when user demand is high= while also making sure you’re not ox'erpaying for computing
`
`resources when you don’t need them.
`
`W'hile it is an extremely useful option. it does require thoughtful configuration in order to- see
`cost savings. When building infrastructure with Auto Scaling, you must be intentional in how
`
`you configure it by thinking carefully about the needs of your sen-'ice in order to reap the most
`benefits.
`
`The basics of Auto Scaling
`
`Auto Sealing can be configured to be flexible in response to more than just CPU usage — if
`
`you‘re more interested in network usage or the length of a queue. that’s possible too. In fact, you
`
`can add or remove resources in response to all kinds of events. You can define custom metrics
`
`

`

`
`http :ffwebceche.qoooleusercontent. comlseerch?q=cache:XIOWIALHN1WJ : bloobuosnao . comlresponsive—i ntrastructure—w
`
`ith—eutosoelinq+&cd=6&hl=en&ct=clnk&qlzus
`0896:0016 0113615? PM
`
`and create scaling rules around any custom values you decide to setup; you just need to supply
`the data.
`
`Another option is to schedule the provisioning of resources instead of doing it dynamically if
`
`you have confidence in the nature of your fixture load. When you‘re very certain what your load
`
`patterns look like then this makes more sense.
`
`The key takeaway here is that you have the ability to scale your resources up and down in
`
`response to pretty much anything you want. This is why Auto Scaling is really powerful.
`
`Bugsnag and Auto Scaling
`
`We discussed it a bit earlier, but at Bugsnag, we have incredibly high and unpredictable load,
`
`and to date, we‘ve processed over 15 billion crashes while retaining 99.9999999% availability.
`
`Our notifiers work across all major programming languages and frameworks, and can be
`deployed on server, mobile, desktop. and client-side JS applications. Their job is to detect and
`
`diagnose every error for our thousands of customers, so anytime one of our customers” users=
`
`experiences an unhandled exception, Bugsnag is notified.
`
`We’ve all been there — you have a bad deploy and you see your datastores go down and the
`
`deluge of errors that result. Whenever something like that happens to our customers, Bugsnag
`
`gets a massive spike in traffic.
`
`This nleams we Itueiu: a huge amuunl of (12113 in a way [hall's ahuust impossible for us to predict,
`
`like when spikes will occur and how large they'll be.
`
`reqs/min over 2 weeks
`
`2x increase
`
`

`

`
`http :ffwebcache.qoooleusercontent. comlsearch?q=cache:XIOWIALHN1WJ : bloobuosnao . comlresponsive—i nfrastructure—w
`
`ith—autoscalinq+&cd=6&hl=en&ct=clnk&qlzus
`0896:0016 0113615? PM
`
`Given all of this uncertainty and the unique nature of our load characteristics, Auto Scaling is
`
`extremely important for us in order to ensure our performance. availability. and customer
`happiness.
`
`Bugsnag’s architecture
`
`Our architecture is setup in multiple layers. Error payloads come into our event servers and are
`
`placed onto queues that get processed by our fleet of event workers. This processing involves
`
`writing information about each event into our datastores, which the Bugsnag dashboard and API
`then read flour to surface data to users.
`
`error payloads
`\.
`
`3V6 nt 56 I'VBI'S
`
`vent workers
`
`\ e
`
`Our main concern is processing incoming payloads at a reasonable rate. Weive made sure that
`
`we always have enough event servers to handle this load. with zero tolerance for
`
`underprovisioning. We can then afford to be more flexible with the availability of event
`
`workers. and have some tolerance for momentary underprovisiong at this level.
`
`In general. are prefer that event server queues are processed quickly by event workers because
`
`this means that the view of the world represented in our datastores is an accurate reflection of
`
`our customers’ application states,
`
`So how does this work in terms of optimizing for availability and cost?
`
`

`

`
`http :ffwebcache.qoooleusercontent. comlsearch?q=caohe:XIOWIALHN1WJ : bloqbuosnao . comlresponsive—i nfrastruoture—w
`ith—autosoalinq+&od=6&hl=en&ot=olnk&q|=us
`0896:0016 0113615? PM
`:
`
` l
`
`J
`
`Event workers
`
`Our event workers are stateless: so no data is stored in their process. This is good because in the
`
`case that an event worker disappears. we haven't actually lost anything. Short term. all data is
`
`stored in our event servers and is then passed along into our various longtertn datastores.
`
`As event workers pull events from the event server queues. they must perform very CPU
`
`intensive processing. The event workers analyze events and write the data to our datastores to
`
`figure out patterns between events and how to aggregate and match them together.
`
`event worker
`
`When we have a spike in error data coming from a customer‘s application. the overall length of
`
`event server queues increases. \Ve try to clear them quickly so that the event data contained here
`can be surfaced to our users fast.
`
`

`

`nttp :rfwebcache.qoooleusercontent. comrsearch?q=cacne:XIOWIALnN1WJ : bloqbuosnao . comrresoonsive—i nfrastructure—w
`ith—autosoalinq+&cd=6&hl=en&ct=clnk&q|=us
`0896:0016 0113615? PM
`
`To do this. we make sure that queue length in the event sen-'ers stays as low as possible, so me
`
`have Auto Scaling rules setup that respond to the length of the payload queue. If the amount of
`work to he done on the queue increases. we add more worker instances to process the queue
`
`more quickly. When the queue length is low and the workers aren=t heavily using CPU. we scale
`
`down to fewer workers to take advantage of the the cost benefits of having less computing
`l'CSOlll'CCS.
`
`event worker
`
`event worker
`
`event worker
`
`Spot and on demand instances
`
`Our eTen worker fleet is made up of on demand and spot Instances.
`
`Spot instances are excess computing capacity that is available in a bidding marketplace. The
`
`pricing for spot instances is based on supply and demand so when there is less excess capacity,
`the spot price increases. and vice versa. If your bid price is more than the current spot price: you
`
`get access to the instances you bid on. The major advantage here is that they’re much cheaper, in
`
`general. that on demand instances. If you‘re looking to use spot instances: it’s important to know
`
`that they can disappear at any time: so your use case needs to be able to tolerate this with
`protection against disappearing instances.
`
`0n demand instances are generally more expensive. but you know you will have them when you
`need them.
`
`

`

`
`http :ffwebcache.qoooleusercontent. comisearch?q=cache:XiOwiALnN1WJ : bloqbuosnao . comiresponsive—i nfrastructure—w
`
`ith—autoscalinq+&cd=6&hl=en&ct=clnl<&ql=us
`0896:0016 0113615? PM
`
`Additional savings from spot instances
`
`We’ve architected our event worker fleet to be made up of both spot and on demand instances=
`so we can take advantage of the low cost of spot instances without negative drawbacks.
`
`We’ve biased our Auto Scaling rules towards the usage of spot instances when they’re available
`
`for their lower cost. They are our first Auto Scaling group and we try to scale them up
`aggressively, and scale down slowly. Our second Auto Scaling group is made up of on denland
`
`instances which we scale up conservatively and scale down aggressively because of their higher
`
`cost. When possible we prefer that spot instances pickup the slack after we scale down on
`demand instances.
`
`There are times when our bid price is below the spot price and so we can’t get spot instances= or
`
`we’re experiencing a particularly large spike which requires both spot and on—demand instances
`to handle.
`
`This spot and on demand approach has proven to be very effective for us and so it’s useful to
`
`consider if spot instances may be able to help you meet your technical challenges too at a lower
`cost.
`
`Conclusion
`
`Auto Scaling might be helpful to your company for achieving high levels of availability and
`
`resource optimization. To get started, AWS elders great developer resources and documentation
`
`to help you decide if Auto Scaling can work for you. Keep in mind that thoughtful configuration
`
`and careful implementation is essential if you decide to use Auto Scaling for your infi'astrucmre.
`
`Share this article
`
`Subscribe to the blog
`
`Bugsnag helps you capture and fix errors in all your applications.
`
`We write about engineering and building Bugsnag.
`
`Learn about bugsnag
`
`

`

`
`http :ffwebcache.qoooleusercontent. comrsearch?q=cache:OoF—SZquiYJitnotes . defdockerfooreosfdeploymenhlayerino
`
`ri nfrastructuretQOt 5i‘03f’l4fresponsive—i nfrastructure—or—how—to—handle—mi croservi ces—with—coreos—and—aws—tr+&cd
`
`=13&hl=en&ct=clnl<&ol=us
`08f26f2016 01:40:0Y PM
`
`This is Goog le's c ac he of httpfliitnotesd efdocken'c oreosideploymendlayeri ngfinfrastru cturel'2 El‘l 5f03f1 Alfrespon sive-infrastruc'tu re-or-how-to—h a'ndleimic'rose rvic es—with-
`fiflffigfiifill‘dfi‘rffiflf- It is a snapshot of the page as it appeared on Aug 24-. 2015 06:33:00 GMT.
`The current page could have changed in the meantime. Learn more
`
`View source
`Text-only version
`Full version
`_i|:. To quickly find your search term on this page. press Ctri+F or NJ: [Mattand use the find bar.
`
`
`Simon Dittlmann
`
`About
`
`My Book Shelf
`
`Pubiications
`
`Responsive infrastructure - or how to handle
`microservices with CoreOS and AWS (1)
`
`This is the first part of a series of three blog articles. This first one gives a more theoretical overview about how I
`layer an infrastructure.
`
`Recently the micro-service architecture style is growing a lot but even without such an architectural approach you
`probably have to run a lot of diflerent software components in your data center to provide a simple application.
`Just think about what you need for a single application you might develop. Your stack could look like the
`following:
`
`DNS entries
`
`IP routing
`firewall settings
`Virtual Machine I Server
`
`operating system
`load balancer
`
`apachefnginx
`tomcat with your application running
`database
`
`log aggregation service
`performance metrics
`
`This means even a simple application needs some other services to run properly. in a more classic approach
`you would setup all the required software once and for each deployment you would replace just your developed
`binary {e.g. your war file]. To have a more scalable approach it’s good to start with a short planning. Let's try to
`sort each of the listed pieces in one of the three followi